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(57) Abstract: In order to provide third party verification of the content and delivery of an electronic message such as an e-mail, 
a server receives the e-mail intended to be sent or forwarded to a specified addressee, and "tags" the message to indicate that it is 
"registered" with the provider of the service. The server then establishes a direct telnet connection with the addressee's Mail User 
Agent (MUA), and transmits the tagged e-mail to the addressee's MUA, as well as to the MUA's of any other addressees. After 
receiving responses from the receiving MUA's that the message was successfully received, the server then creates and forwards to 
the message originator an electronic receipt. The receipt include one or more, and preferably all of, the following: the original 
message including any original attachments; a delivery success/failure table listing which addressee's MUA's successfully received 
message and at what time, and for which MUA's there was a delivery failure; and a digital signature corresponding to the message 
and attachments. By receiving the receipt at a later date and verifying that the digital signature matches the message and related 
information, the operators of the system can provide independent third party verification that the receipt is a genuine product of their 
system and that the information pertaining to content and delivery of the message is accurate, without the need to archive either the 
original message or the receipt. 
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SYSTEM AND METHOD FOR VERIFYING DELIVERY AND 
INTEGRITY OF ELECTRONIC MESSAGES 

BACKGROUND OF THE INVENTION 

5 

I. Field of Invention 

This invention relates generally to a system and method for verifying delivery and 
content of an electronic message and, more particularly, to a system and method of later 
1 0 providing proof regarding the delivery and content of an e-mail message. 

II. Description of the Related Art 

hi recent years e-mail has become an indispensable business tool. E-mail has 
1 5 replaced "snail mail" for many business practices because it is faster, cheaper and generally 
more reliable. But there remain some mail applications where hard copy is still dominant, 
such as registered and certified mail. For example, when a letter is sent by certified mail 
the sender is provided with a receipt to prove that the letter was mailed. A returned 
registered mail receipt adds the Postal Service's confirmation that the letter was 
20 successfully delivered to the addressee or the addressee's authorized agent. Additionally, 
private couriers such as Federal Express® and United Parcel Service® (UPS) provide 
some type of delivery confirmation. Since every piece of courier mail is, in effect, 
registered it is natural for consumers to turn to these services when they want proof of 
delivery. 

25 Many existing e-mail systems and e-mail programs already provide for some form 

of proof of delivery. For instance., some e-mail systems today allow a sender to mark a 
. message with "request for notifications" tags. Such tags allow a sender to request 

notification that the message was delivered and/or when the message was opened. When a 
sender requests delivery notification, the Internet e-mail system may provide the sender 

3 0 with an e-mail receipt that the message was delivered to the mail server or electronic inbox 
of the recipient. The receipt message may include the title of the message, the 
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destination address, and the time of delivery. It may also include (depending on the 
types of "flags" that are provided and activated in the mailing software) a list of all the 
Internet "stations" that the message passed through en route to its destination. This form 
of reporting is built into some of the rules and protocols which implement e-mail. 
Furthermore, when a message is sent with a "read notification" request, the recipient's e- 
mail program may send to the sender an e-mail notification that the recipient opened that 
message for reading. Many electronic mail clients can and do support this kind of 
reporting; however, Internet protocols do not make this mandatory. 

However, this does not mean that an e-mail sent with a notification request is as 
effective in all respects as registered mail. People certify and register letters because 
they want proof of delivery, e.g., proof that can be used in a civil or criminal proceeding, 
or proof that will satisfy a supervisor or a client or a government agency that a message 
has been sent, a job has been done, an order placed, or a contract requirement satisfied. 

A registration receipt from the United States Postal Service (USPS) constitutes 
proof of delivery because the USPS stands behind it. The receipt represents the Post 
Office's confirmation that the letter or package in question was actually delivered to the 
addressee or his authorized representative. On the other hand, with the e-mail receipt 
various hurdles exist to an e-mail receipt being admitted and relied upon as persuasive 
evidence in a court of law as a proof that the message was delivered. After all, the 
receipt may be just another e-mail message that could have been altered or created by 
anyone, at any time. 

There exists a need for an e-mail system and/or method that can provide reliable 
proof of the content and delivery of an e-mail message in order to take fuller advantage 
of the convenience and low cost of communicating via e-mail. 

To meet this need some systems have been established whereby senders may 
receive third party proof of delivery by enrolling in services whereby: 

a) The sender transmits an electronic message to a third party together 
with a list of the document's intended recipients. 

b) The third party sends a notification to each of the message's intended 
recipients inviting them to visit the third party's web site where the 
message can be viewed. 
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c) If the intended recipient visits the third party's web site to view the 

message, the third party records this visit so that the sender may know 
that his message has been read by the recipient. 
The drawbacks of such systems are manifold. In the first place they rely 
essentially on the co-operation of the recipient of the e-mail to collect their messages 
from the third party's service. But the circumstances in which a sender may want proof 
of delivery of a message are often ones in which it cannot be assumed that the intended 
recipient will co-operate in receiving the message. In such cases, e.g. where 
acknowledging receipt of the message would place a financial or legal burden on the 
recipient, the recipient can simply ignore the notification that mail is available for him to 
receive. Note that there is nothing in such a system to guarantee that the intended 
recipient has received notification of waiting mail. In the second place, such systems are 
cumbersome and slow to use as compared to regular e-mail insofar as it can require the 
sender and/or the recipient to connect to a World Wide Web site to send, collect and 
verify the delivery of each message. Moreover, transmission of documents by such 
methods may require both sender and receiver to upload and download files to a web 
site. Finally, because these methods require the third party to retain a copy of the whole 
of each message until such time as they are collected or expired, the methods can require 
its provider to devote substantial computational resources to data storage and data 
tracking over an extended period of time. As an alternative method of providing proof of 
delivery, some systems provide proprietary e-mail clients or web-browser plug-ins that 
will notify senders when a message has been received provided that a recipient uses the 
same.e-mail client. The obvious disadvantage of such systems is that they require both 
sender and recipient to use the same e-mail client. 

Therefore, there exists a need for an e-mail system/method that can provide 
reliable proof of the content and delivery of electronic messages which does not require 
the compliance or co-operation of the recipient, which requires no special e-mail 
software on the part of sender or recipient, which operates with the same or nearly the 
same convenience and speed of use as conventional e-mail, and which can be operated 
3 0 economically by a service provider. 
SUMMARY OF THE INVENTION 

A general object of the present invention is to provide a system and method for 
reliably verifying via secure and tamper-proof documentation the content and delivery of 
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an electronic message such as an e-mail. Ideally, the invention will give e-mail and other 

electronic messages a legal status on a par with, if not superior to, that of registered 

United States mail. However, it is not necessary to the invention that any particular legal 

status is accorded to messages sent according to the methods taught herein, as the 

invention provides useful information and verification regardless. 

The present invention includes an electronic message system that creates and 

records a digital signature of each electronic message sent through the system. An 

originator may send a copy of the electronic message to the system or generate the 

electronic message within the system itself. The system then forwards and delivers the 

electronic message to all recipients (or to the designated message handlers associated 

with the recipients), including "to" addressees and "cc" addressees. Thereafter, the 

system returns a receipt of delivery to the originator of the electronic message. The 

receipt includes, among other things: the original message, the digital signature of the 

message, and a handshaking and delivery history including times of delivery to the 

recipients. To later verify and authenticate information contained in the receipt, the 

originator or user sends a copy of the receipt to the system. The system then verifies that 

the digital signature matches the original message and the rest of the receipt. If the two 

match, then the system sends a letter or provides other confirmation of authenticity 

verifying that the electronic message has not been altered. 

The system may be a form of e-mail server connected to the Internet, which can 

be utilized in many ways. For instance, individual users can register their electronic 

messages, such as e-mails, by sending a "carbon copy" (cc:) to the system or composing 

the message within the system itself. For corporate or e-commerce users, these users can 

change their server to a server incorporating the present invention and have all of their 

external electronic messages registered, with the option of having the system retain and 

archive the receipts. The system can accept and verify encrypted electronic messages 

and manage the electronic messages within and/or outside a "fire wall" For web-based 

users, i.e., individuals or corporations using web-based e-mails, such as MSN Hotmail® 

or Yahoo Mail®, such users could check a box or otherwise set a flag within their e-mail 

programs to select on a case-by-case basis whether to register the e-mails and/or to 

archive the messages using the present system. 

The digital signature can be created using known digital signature techniques, 

such as by performing a hash function on the message to produce a message digest and 
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then encrypting the message digest. Separate digital signatures can be created for the 
body of the message, any attachments, and for the overall message including the body, 
the attachments, and the individual message digests. The encrypted message digest ' 
provides one type of message authentication or validation code, or secure documentation. 
Other message authentication and/or validation codes may also be generated and used. 

In one aspect, the invention is a method of providing proof regarding the delivery 
and content of an electronic message, comprising: receiving from a sender across a 
computer network an electronic message, the message having a delivery address 
associated therewith; computing a message digest according to the message; encrypting 
the message-digest; sending the message electronically to a destination corresponding to 
the delivery address; recording the Simple Mail Transport Protocol (SMTP) or Extended 
SMTP (ESMTP) dialog which effects the delivery of the message; receiving Delivery 
Status Notification information associated with the message and the delivery address; 
providing to the sender an electronic receipt, the receipt comprising: a copy of the 
message, the encrypted message digest, the (E)SMTP transcripts, and at least a subset of 
the Delivery Status notification information, and, at a future date, receiving electronically 
the electronic receipt from the sender, verifying that the encrypted message digest 
corresponds to the message, and verifying that the message was received by an electronic 
message handler associated with the delivery address. 

In another aspect, the invention is a method of verifying delivery of an electronic 
message, comprising: in a wide area network computer system, receiving an electronic 
message from a message sender for routing to a destination address; establishing 
communication with an electronic message server associated with the destination 
address, the server defining a destination server; querying the destination server to 
determine whether the destination server supports Delivery Status Notification (DSN) 
functionality; receiving a response to the query, the query and response together defining 
an SMTP dialog; requesting Delivery Status notification information from the 
destination server according to results of the SMTP dialog; transmitting the electronic 
message to the destination address; receiving DSN information from the destination 
server with respect to delivery of the electronic message; and providing to the message 
sender at least a portion of the SMTP dialog, and at least a portion of the DSN 
information. 
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In yet another aspect, the invention is a method of verifying content of a received 
electronic message, comprising: receiving the electronic message; generating a digital 
signature corresponding to content of the received message; providing the message and 
the digital signature to a designated addressee; and, at a later time, verifying that the 
5 digital signature corresponds to the message. 

In accordance with still another aspect of the present invention, the method 
includes establishing whether a message was electronically received by a recipient, 
comprising: providing a message to be dispatched electronically along with a recipient's 
address from a sender; creating a signature associating with the message; dispatching the 

10 message electronically to the recipient's address; tracking the message to determine a 

final Delivery Status of the message dispatched to the recipient's address; upon receiving 
final Delivery Status of the message, generating a receipt, the receipt including a copy of 
the message, the signature, and the final Delivery Status for the message; and providing 
the receipt to the sender for later establishing that the message was electronically 

1 5 received by the recipient. 

In accordance with yet another aspect of the present invention, a method is 
provided for proving that an electronic message sent to a recipient was read, comprising: 
providing an electronic message along with a recipient's address; calculating a digital 
signature corresponding to the electronic message; dispatching the electronic message 

20 electronically to the recipient's address; requesting a Mail User Agent (email client 
"reading") notification from the recipient; upon receiving the reading notification, 
generating a reading receipt, the reading receipt including a copy of the message, the 
digital signature for the corresponding electronic message, and a second digital signature 
for the reading receipt from the recipient; and providing the reading receipt for later 

25 verification that said message was received by the recipient. 

In accordance with another aspect of the present invention, a method is provided 
for validating the integrity of a purported copy of an electronic message, comprising: 
receiving the purported electronic message copy, said purported copy including an 
encrypted message digest associated therewith; decrypting the message digest; 

30 generating a second message digest based on content of the purported copy; and 

validating the purported copy by comparing the decrypted message digest and the second 
message digest to determine whether the two message digests match. 
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In accordance with a still further aspect of the present invention, a method is 
provided for validating a received registered e-mail, comprising: receiving an electronic 
receipt, said receipt including a base message and an encrypted message digest; 
decrypting the encrypted message digest; generating a second message digest from the 
base message; and validating the e-mail if the decrypted message digest matches the 
second message digest. 

In yet another aspect, the invention is of a website at which users can go to send 
and receive secure messages, with the website host acting as an independent third party 
which will send and receive the messages and provide secure documentation regarding 
the content and delivery of the messages. 

The above-described objects of the present invention and other features and 
benefits of the present invention will become clear to those skilled in the art when read in 
conjunction with the following detailed description of a preferred illustrative 
embodiment and viewed in conjunction with the attached drawings in which like 
numbers refer to like parts, and the appended claims. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Detailed description of the preferred embodiment of the invention will be made 
with reference to the accompanying drawings. 

FIG. 1 is a system diagram of a first embodiment of the present invention, in 
which outgoing messages are registered by being transmitted by a special Mail Transport 
Agent (MTA). 

FIGS. 2A-2F constitute a representative flow diagram for registering an outgoing 
e-mail according to the embodiment of FIG. 1 . 

FIG. 3 is a system diagram of a second embodiment of the present invention, in 
which senders may direct a Mail Transport Agent to transmit selected messages tough 
a separate registering MTA. 

FIG. 4 is a system diagram of a third embodiment of the present invention, in 
which carbon copies (cc's) of outgoing messages are sent to a special server to be ' 
registered. 

FIG. 5 is a system diagram of a fourth embodiment of the present invention, in 
which users compose outgoing messages to be registered at a designated website. 
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FIG. 6 is a system diagram of a fifth embodiment of the present invention in 
which users may send registered e-mails and store receipts from within a Web Based 
Mail User Agent (MU A) . 

FIG. 7 is a flow diagram for validating a registered e-mail receipt. 

FIG. 8 is a system diagram of an embodiment of the present invention for 
registering incoming messages. 

FIG. 9 is a flow diagram for registering incoming messages. 

FIG. 10 is a flow diagram for validating received registered messages. 

FIG. 11 is a system diagram showing an exemplary use of the present invention 
by an e-business to register and acknowledge incoming and outgoing communications. 
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DETAILED DESCRIPTION OF THE INVENTION 

This description is not to be taken in a limiting sense, but is made merely for the 
purpose of illustrating the general principles of the invention. The section titles and 
overall organization of the present detailed description are for the purpose of 
convenience only and are not intended to limit the present invention. Accordingly the 
invention will be described with respect to e-mail messaging systems that use the ' 
Internet network architecture and infrastructure. It is to be understood that the particular 
message type and network architecture described herein is for illustration only the 
invention also applies to other electronic message protocols and message types' using 
other computer network architectures, including wired and wireless networks. For 
convenience of discussion, messages that are processed according to the present 
invention may be referred to herein as being "registered" messages. In the discussion 
which follows, the term "RPost" will refer in general terms to a third party entity which 
creates and/or operates software and/or hardware implementing the present invention 
and/or acts as a disinterested third party message verifier. The term is used for 
convenience of exemplary discussion only, and is not to be understood as limiting the 
invention. 

I. RPOST AS OUTGOING MAIL SERVER EMBODIMENT 

FIG. 1 is a system diagram of a first embodiment of the present invention 
wherem outgoing e-mails are registered according to the present invention. In this 
embodiment, the RPost registering server 14 serves as the primary outgoing Mail 
Transport Agent (MTA) for a message sender's Mail User Agent (MUA) 13. Although 
message recipient 1 8 is technically the addressee and is therefore merely the intended 
rec ipi ent or intended destination at this point in time, for simplicity of discussion this 
entity will be referred to herein as the recipient, addressee, or destination. Note that a 
single message may have many different destinations and that each of these may be 
reached through a different MTA. 

The method of sending registered messages may divided into three parts: 

V Preprocessing: Steps to be taken before a message is transmitted; 
2) Transmission: The method of delivering messages to addressees;' 
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3) Post Processing: Procedures for gathering information about 
messages after their delivery, the creation of receipts, and the 
validation of receipts. 

1.1 Preprocessing 

5 . On receiving a message for transmission, the RPost server will create records in a 

database for each message that will be used to store such information as: 

a) the time at which the message was received; 

b) the names of the attachments of the message; 

c) the number of addresses of the message; 

1 0 For each destination of the message the database will record: 

a) the name of the destination (if available); 

b) the internet address of the destination; 

c) the time at which the message was delivered to the destination's Mail Server; 

d) The Delivery Status of this destination 

15 Recipient Delivery Statuses used by the system will include: 

UNSENT 

This status indicates that the message has not been sent. 
DELIVERED-AND-W AITIN G-F OR-D SN 

This status indicates that the message has been delivered to an 
20 ESMTP compliant MTA that supports Delivery Status 

Notification (DSN) so that a success/failure notification can be 
expected. 
DELIVERED 

This status signifies that the copy of the message sent to this 
25 recipient has been successfully delivered to a server that does not 

support ESMTP DSN. 
DELIVERED-TO- MAILBOX ~~ 

This status signifies that a DSN message has been received which 

indicates that the copy of the message sent to this recipient was 
30 delivered to the mailbox of the recipient 
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RELAYED 

This status signifies that an MTA DSN has been received which 
indicates that the copy of the message sent to this recipient has 
been relayed onward to another server. 
UNDELIVERABLE 

This status indicates that after repeated attempts RPost has been 
unable to connect to an MTA to deliver the messages to this 
recipient. 
FAILED 

This status signifies that an MTA DSN has been received that 
indicates a failure to deliver a copy of the message to this 
recipient. 

At this time the system will also perform hashing functions on the message's 



RPost server 14 employs a hash function and an encryption algorithm. The hash 
ftmction may be one of any well-known hash functions, including MD2, MD5, the 
Secure Hashing Algorithm (SHA), or other hash functions which may be developed in 
the future. Hash algorithms and methods are-described in Bruce- Schneider, Applied 
Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, Inc. 
(New York) 1993; Federal Information Processing Standard Publication 1 80-1 (MPS 
PUB 180-1) Secure Hash Standard, National Institute of Standards and Technology; and 
U.S. Pat. No. 5,530,757 issued to Krawczyk, entitled "Distributed Fingerprints for 
Information Integrity Verification," which are hereby incorporated by reference for their 
teachings of hash functions, encryption, and methods and systems for implementing 
those functions. Other known or new methods of detecting whether the contents of the 
message have been altered may be used. 

A good haih function H is one-way; that is, it is hard to invert where "hard to 
invert" means that given a hash value h, it is computationally infeasible to find some 
input x such that H(x) = h. Furthermore, the hash function should be at least weakly 
collision-free, which means that, given a message x, it is computationally infeasible to 
find some input such that H(x) = H(y). The consequence of this is that a would-be 
forger who knows the algorithm used and the resulting hash value or message digest will 
nevertheless not be able to create a counterfeit message that will hash to the same 

1 1 
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number. The hash value h returned by a hash function is generally referred to as a 
message digest. The message digest is sometimes referred to as a "digital fingerprint" of 
the message x. Currently, it is recommended that one-way hash functions produce 
outputs that are at least 128 bits long in order to ensure that the results are secure and not 
forgeable. As the current state of the art advances, the recommended length for secure 
hash functions may increase. 

RPost server 14 computes a message digest for the message body, and a separate 
message digest for each of the attachments of the message and stores these in a manner 
in which they may be later included in a receipt for the message. 

Before the message is altered in the ways that registration will require, a copy of 
the original message and its attachments are stored in a manner in which they can be later 
retrieved by the system. 

The RPost server may alter a message in several ways before transmission to the 
recipient's MTA. 

Although such is not necessary to the practice of the invention, the message may 
be tagged to denote the fact that the message has been registered, such as by inserting the 
word "Registered" or at the beginning of the "subject" line of the message, by appending 
a tag such as: . 

"This message has been registered with RPost. Visit our web site at 

www.RPost.com for additional information." 
at the end of the original message or other tagging. Additionally, the tag may contain 
instructions, World Wide Web addresses, or links that invite and allow the recipient to 
send a registered reply to the message by linking to a Web Page from which registered 
messages may be composed and sent. 

Although tagging is optional, the delivered message will generally be referred to 
herein as the tagged message. 

Internet protocols provide two forms, of receipt for e-mail messages: 

MTA NOTIFICATIONS 

These are e-mails that are sent by a recipient's MTA notifying the nominal 

sender of the message that various events have occurred. MTAs that conform to 

the SMTP protocol will typically only send a notification in the event that the 

mailer cannot deliver a message to the mailbox of the addressee (as might happen 
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if the address is not valid or if the addressee's mailbox has exceeded its allotted 
storage quota). 

With the introduction of the Extended SMTP standard it became possible 
for sending MTAs to request notices of success and failure in the delivery of 
5 messages. These Delivery Status Notifications (DSNs) are e-mails which are 

sent by a receiving MTA to the nominal sender of the message when certain 
events occur: e.g. the message has been successfully deposited into the mailbox 
of the recipient; the message cannot be delivered to the recipient's mailbox for 
some reason; the recipient's message has been relayed on to another server which 
1 0 does not give DSN receipts. 

Note that only e-mail servers that support the Extended SMTP (ESMTP) 
protocol support this form of DSN and that support for this function is optional 
for ESMTP servers and depends on the configuration selected by the server's 
administrators. 

Although DSN is a term that only came into use with the advent of 
ESMTP, we wilL in what follows, use DSN' to refer to any MTA generated 
message relating to the status of a received message whether or not it is in 
conformity to the ESMTP protocol. 
MUA NOTICES (READING NOTIFICATIONS 

These are emails that are sent to the (nominal) author of a message by the 
recipient's Mail User Agent (MUA) (e-mail program) when certain events occur: 
e.g. the message is opened for reading, or deleted from the system without being 
read. By Internet convention (RFC 1 891), no MUA program can be forced to 
generate such notifications. Whether an MUA will generate these receipts will 
depend upon the configuration chosen by its user. 

The RPost server 14 will configure and transmit messages in a way that attempts 
to elicit both MTA DSNs and MUA notices fromTompliant MTAs and MUAs. In order 
to elicit a Reading Receipt from compliant MUAs, certain headers must be included in 
the header section of an e-mail message. Different MUAs respond to different headers; 
hence Server 14. will add several different headers to each message requesting a read 
notification in a form recognized by various MUAs. These headers all take the form: 

Header label: user name <user address> 
For example; 
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Disposition-notification- to: john smith < jsmith@adomain.com> 
read -not if i cat ion- to: john smith <j smi th@adoma in . com> 

where 'john smith 5 is the name of the user to whom an MUA notification is to be sent 
and '<jsmith@adomain.com>' is that user's Internet address. Normally such headers 
would refer to the author of the message but in the case of the present method it is 
required that the notification be returned to RPost so that the notification can be 
processed by RPost. To assure that this is so Server 14 will insert headers that request 
that MUA receipts be sent to an address where they can be processed by the RPost 
server, for example: " readreceipt@RPostcom ". This will direct any compliant recipient 
MUAs to send their notifications to an RPost address for processing. 

The task of processing returned MUA notifications raises another problem that 
must be dealt with at this stage. There are no standards governing the format or content 
of MUA notifications. Often they will quote the subject of the original message and the 
time of the event (e.g. "opened for reading 35 ) that they are reporting. But even if this 
information is included in the notification it is rarely sufficient to uniquely identify the 
message that prompts it or to identify the author of that message. When the system 
receives a MUA notification it must be able to identify the message that prompts it, so as 
to include the notification information in the receipt that RPost will generate.foxthe. 
sender. Alternatively, the system must at least be able to reliably identify the sender of 
the message to which the MUA notification refers so that the notification information 
can be passed on to the sender in the form of an RPost Reading receipt (see below). 

To accomplish the latter goal, the system can take advantage of the fact that 
internet addresses have two components: a name field and an address field, where the 
address field is set off by comer quotes "o". Most MUAs will include both fields in the 
destination address of their MUA notifications. In composing its requests for MUA 
receipts, the RPost system will include the Server 14 read receipt-handling address as the 
address for the notification but will use the address of the original sender in the name 
field of the header. For example, where the original sender of the message is user John 
Smith with Internet address ismithro),adomain.com . the RPost server will include headers 
of the fonn: 

Disposition-notification- to : j smi th@adomain . com <readreceipts@KFos t . com> 

This will typically result in the compliant MUA sending a notification to 
readreceipt s<@RPnst com adressed as: 
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jsmithsadomain. com <readreceipts@RPc.st . eom> 

On receipt of such a notification at the address ' 'readreceipts@RPost.com", the server 
can, by parsing the addressee's field, determine that the notification concerns a message 
originally sent by ■ imm^Mm^corn, even if this could not be determined by any 
5 examination of the contents of the notification. With this information in hand, the server 
can then package the contents of the notification in a digitally signed RPost Reading 
receipt and send the receipt to the address ismith@adon^ gom 

The RPost system will also endeavor to elicit and collect MTA DSN notices 
generated by recipient MTAs. Since such notifications are always sent to the address 
10 listed in the "FROM:" field of the message header, server 14 must alter each message 
header so that the message is received as "FROM:" an RPost address at which DSNs 
may be processed. 

However the problem of processing DSNs raises another issue, which must be 
dealt with at this stage. DSNs do not have any standard content or_format; often it is 
1 5 impossible to determine, merely by examining the contents of these e-mails, what 

message their, contents are giving notification of. This problem was supposed to have • 
been addressed for DSNs generated in compliance with the ESMTP protocol by the use 
of DSN envelope ID numbers (see RFC 1 869). According to the protocol, a transmitting 
MTA can include a reference number along with its request for a DSN. This number 
10 would be quoted in any returning DSN, allowing the sender to identify the subject 

message of the DSN. However, as a matter of fact, many MTAs that report themselves 
as supporting ESMTP DSN do not return a DSN envelope ID or any other information 
sufficient to reliably identify the subject message. Finally, even where a DSN does 
return mfonnation sufficient to identify the message it is giving notice of, it often will 
5 not contain sufficient information to identify the specific addressee of the message that 
has prompted the notification. Thus, a single message might be sent to two addressees at 
a domain; one might be successfully delivered to the addressee's mailbox; the ofiieTnot 
The MTA for the domain may report these events in a DSN in ways that provide no way 
for the recipient of the DSN to determine which addressee was successfully delivered 
' and which was not (as, for example, may happen if the DSN reports the recipient's 

addresses as their local alias names rather than by the addresses contained in the original 
message). 

The present invention solves this problem in four steps: 
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1) A unique identification number is generated for each outgoing 
message (e.g. based upon a time stamp). This number is stored in a 
database. 

2) The recipients of each message are enumerated and the identifying 
numbers are stored in a database. 

3) The message is sent separately to each intended recipient's MTA. 
(Even when two recipients have a common domain name and 
MTA, the server 14 will transmit the message to that MTA in two 
separate SMTP telnet sessions.) 

4) When Server 14 transmits the message to a recipient's MTA it 
augments the message's "FROM" field to show the message as 
having been sent from an address which incorporates the 
message's unique ID and the identifying number of the sender. 
The address .also, contains a substring (e.g. "rcpt") that enables the 
Server to identify return messages as DSNs. 

Thus, a single message denominated "mmyyddss" by Server 14, from the sender 
named John Smith, might be sent to its first intended recipient (denominated "a" by the 
system) with a header reading: 

Prom: John Smith <rcptromddyyssa@RPost . com> 

The same message would be sent to the second recipient with a header reading: 

From: John Smith <rcptmmddyyssb@RPost . cozn> 

Many e-mail MUAs will only display the name of the sender of a message and thus the 
special address will be unseen by most recipients. 

The upshot of this form of addressing is that when the recipient MTAs issue 
DSNs (whether ESMTP compliant or not) they will address those DSNs to different 
RPost addressees. On receiving these DSNs, Server 14 can identify them as DSN 
messages by their "RCPT" prefix and, by parsing the addressees/ can determine which 
message and which recipient is the subject of the DSN. 

System 14 will alter the 'FROM' field of each message to refer to a recipient of 
the message each time it attempts to transmit the message to that recipient's MTA. 

To insure that recipient replies to transmitted messages are directed properly 
system 14 will add an explicit "reply-to:" message header into the message listing the 
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original sender's name and Internet address. In the case of the present example this 
would be: 

Reply- to: john smith <jsmith@adomain.com> 

This will lead recipient MUAs to address replies to a received message to the actual 
5 sender's address, rather than the constructed RPost address. 

1.2 Transmission 

As noted above, it is part of the method that the RPost server transmits a separate 
copy of an outgoing message to each addressee of that message. Moreover RPost will 
attempt to make each such delivery through a direct SMTP connection with a mail 
1 0 exchanger (MX) of record for each destination: 

Note: Each valid Internet e-mail address includes an Internet domain name or IP 
address. Each domain name/ address has associated with it an e-mail server(s) 
authorized to receive mail for addresses in that domain. It will.be noted that some, 
domains have more than one server. The Domain Name Server responsible for each 
domain broadcasts the identity of its mail servers across the Internet. This information is 
publicly available and is managed and transmitted in ways that conform to rules and 
conventions which- govern Internet e-mail and Domain-Name service. 

Before transmitting a copy of a message to any destination the RPost server will 
perform an Internet Name Server Lookup to identify an MTA associated with the 
destination's domain. Having identified the MTA responsible for receiving mail on 
behalf of a destination address, the system will attempt to open a telnet connection with 
the destination's local MTA. 

It is common practice for Internet e-mails to be relayed from MTA to MTA until 
they reach their final destination. The primary purpose for requiring a djrecLconnection 
between the RPost server and the destination's MTA is so that the RPost server can 
record delivery of the message, (this record taking the form of an SMTP dialogue) with 
the e-mail server which has proprietary responsibility for receiving e-mail for the 
recipient domain name. 

The existence of this record provides helpful evidence that the message was 
delivered, in much the same way that a registered mail receipt provides evidence of 
delivery. USPS Registered mail is treated as verifiably delivered if it can be proved to 
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have been delivered to the addressee's authorized agent (e.g. a secretary, or mail room 
clerk). In the event of any legal challenge to the evidentiary merit of an RPost delivery 
receipt, it will be recognized that in selecting an Internet e-mail service provider, the 
recipient has authorized that provider to collect electronic messages on his behalf. In 
5 turn, that service provider has acknowledged its status as the authorized agent for e-mail 
recipients of that domain name by broadcasting the address of its MTAs as the receptive 
e-mail servers for this domain. 

Accordingly, having delivered messages directly to the mail server responsible 
for receiving the recipient's e-mail, RPost will have delivered the message to an agent 
1 0 the recipient has legally authorized to receive his mail. By recording the delivery 

transaction (that transaction taking the form of an SMTP dialogue) RPost can claim to 
have proof of delivery to the recipient's authorized agent 

Note that while the method herein described attempts" to collect other forms of 
proof of delivery to each destination,.whether or_not these- attempts succeed will depend 
5 upon factors that, will not be in controlof RPost, (e.g. the form of SMTP support 

deployedon the recipient's mail server). On the other hand, every successful delivery 
direct to a recipient's mail server will always generate an SMTP record. Recording this 
record allows RPost to provide proof of delivery to any valid Internet destination that 
complies with the minimum protocols (SMTP) for Internet mail. This represents an 
0 important advantage of the current method over other methods that might attempt to 
prove delivery by reliance on ESMTP DSN. 

Having identified the MTA for a destination of a message, the RPost server will 
attempt to open an ESMTP connection with the destination MTA by issuing an "EHLO" 
handshake in compliance with RFC 1 869. If SERVER 1 6 supports ESMTP, it will 
respond by listing which ESMTP services it supports. 

If SERVER 16 supports ESMTP, the RPost server will first determine if 
SERVER 16 supports the ESMTP Service "VERIFY". -The Verify; service allows a 
calling SMTP server to determine, among other things, if an address in an MTA's 
domain is genuine. If the RPost Server determines by these means that the address if is 
attempting to deliver its message to is not valid, it will terminate the connection, cease 
attempting to deliver a message to this addressee, and record, in its database, the status of 
this message destination as UNDELIVERABLE. 
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Whatever its result, the RPost Server will record the ESMTP VERIFY dialogue 
in a file and store it so that it may be later attached to or included in the Delivery Receipt 
for this message. It should be noted that, out of concern for security, few ESMTP 
servers support the VERIFY function. 

If System 1 6 does not support the VERIFY method, then the RPost server will 
nevertheless attempt to deliver the message to System 16. Typically an MTA will accept 
messages for any address nominally in its domain and will later send a DSN if the 
address is invalid. 

The RPost server will then attempt to determine if the destination server supports 
the ESMTP service DSN. If it does, RPost will transmit the message with a request that 
SERVER 16 notify the sender of the message 'with an ESMTP DSN if the delivery to the 
addressee succeeds or fails. After the successful transmission of the message to this 
destination the system will record the Delivery Status of this destination as 
DELIVERED- WAITING-FOR-DSN. 

If Server 1 6 replies to the "EHLO" handshake in a way that indicates that it does 
not support ESMTP, the RPost server will issue a "HELO" message to initiate an SMTP 
connection. If this connection is achieved, the RPost server will transmit the message in 
compliance with the SMTP protocol and willTecordthe Delivery Status of the 
destination as DELIVERED. 

Whether the connection is SMTP or ESMTP, the RPost server will record the 
entire protocol dialogue between the two servers. Typically this dialogue will include 
protocol messages in which, among other things, the destination server identifies itself, 
grants permission to upload a message for a named recipient, and acknowledges that the 
message was received. RPost will save the record of this transaction in such way that it 
may be later retrieved and included in or attached to the RPost Delivery Receipt for this 
message. 

For various reasons RPost may not be able to achieve an SMTP connection with 

an MTA of a recipient or it may achieve such a connection but be denied permission to 

transmit the message by the recipient. In that case, if the Internet DNS lookup reveals 

that the destination address is served by multiple MTAs, the RPost server will attempt to 

deliver its message to each of these in turn. RPost will continue to attempt to deliver to 

•an appropriate MTA as often as system resources permit. If, after a length of time, RPost 

cannot deliver the message to an address, it will mark the status of this recipient of this 
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message as "UNDELIVERABLE" and stop attempting to send this message to this 
destination address. 

When the RPost server succeeds in transmitting a message to a destination Server 
that explicitly supports ESMTP DSN, RPost will record the status of this recipient for 
this message as "DELIVERED-AND-WAITING-FOR-DSN". 

When the RPost server succeeds in transmitting a message to the destination 
Server via a connection that does not explicitly support ESMTP DSN, RPost will record 
the status of this recipient for this message as "DELIVERED." 

1.3. POSTPROCESSING 
DSN Processing 

MTA DSNs will be returned to the RPost Server addressed to fictitious addresses 
in its proprietary domain (e.g. ''RPost. com"), these addresses having been constructed as 
described above. The RPost server will scan all inbound mail addressed to the domain 
and detect DSN messages by their identifying substring (e.g. "rcpt"). By parsing these 
addresses in the manner described above, the system can identify the message and the 
recipient that has prompted the DSN notification. 

There is no standard format for DSN messages; neither is there any standard 
lexicon in which they report their results. To evaluate a received DSN the system must 
look in the subject line and the body of DSN messages for words and phrases that 
express the DSN's meaning. For example, such phrases as "successful delivery" or 
"delivered to mailbox" or "was delivered" normally signal that the message the DSN 
concerns was deposited to the mailbox of the destination. When it detects such phrases 
the System will change the Delivery Status of this destination of the message to 
"DELIVERED TO MAILBOX". 

Phrases such as "could not be delivered", "fatal error", "failure" and 
"unsuccessful" typically signal a DSN that reports a failure by the MTA to deliver the 
message to the destination. When it detects phrases such as 'these in the DSN the system 
will change the record of the recipient's Delivery Status to "FAILED". 

Though the system always delivers mail to a proprietary MTA for the 
destination's domain, these MTAs will sometimes relay the message to a different server 
(as may be the case, for example, if the receiving MTA sends mail behind a firewall). In 
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this case the DSN will contain such phrases as "relayed" or "relayed onward". In such 
cases the system will change the recipient's Delivery Status to "RELAYED". 

Having evaluated the DSN and updated the recipient's Delivery Status 
accordingly, the system will save the DSN and any attachments it may contain in such a 
way that this message(s) may be included in and/or attached to an RPost Delivery 
Receipt. 

Message Management 

From time to time the system will scan each sent message and examine the status 
of each destination of that message in order to determine if the system has completed 
processing of that destination's delivery. The criteria for completion depend upon the 
destination's Delivery Status: 

DELIVERED: This status indicates- that a copy of the message for this 
recipient has been delivered to an MTA that does not support ESMTP DSN. 
Such an MTA may nevertheless send a form of Delivery Status Notification in 
the event that the message could not be delivered to the Mailbox of the addressee 
(as might happen, for example, if the destination address does not correspond to a 
valid account within the domain). Accordingly, the system will not treat the 
delivery for such a recipient as completed until a period of time has elapsed since 
the delivery to the recipient MTA. This time period— typically two to twenty- 
four hours- represents an estimate of the maximum time required for a majority 
of servers to return a notification of a failure to deliver and it may be adjusted if 
the specific destination domain is remote or known to be prompt or tardy in 
producing such notifications. 

RELAYED: This status signifies that a DSN has been received that 
indicates that the recipient MTA has forwarded the message to another MTA that 
does not support ESMTP DSN. Inthis case it is nevertheless possible that the 
MTA to which the message has been delivered will send a notification of failure 
to deliver in due course. Accordingly recipients with this status are treated as 
complete under the same conditions as recipients with the status DELIVERED. 

DELIVERED- AND- WAITING-F OR-DSN : This status indicates that the 
recipient's MTA supports ESMTP DSN and that a DSN has been solicited but 
not yet received. It may sometimes happen that although an MTA identifies itself 
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as supporting this service it will nevertheless not provide DSNs even in the event 
of successful delivery. Accordingly, the system will regard deliveries to a 
destination with this status as completed even if no DSN is received after an 
interval of time. This interval - typically six to twenty-four hours- represents an 
estimate of the maximum time typically required for a compliant MTA to return a 
DSN. 

DELIVERED-TO-MAILBOX: This status indicates that a DSN 
indicating successful delivery has been received for this recipient and hence the 
delivery of the message to this destination is completed. 

FAILED, UNDELIVERABLE: Deliveries to recipients with this status 
are always treated as complete. 

When the system finds that delivery to all recipients of a message has been 
completed the system will construct a Delivery Receipt for the message. 

Creation of Delivery Receipts 

Delivery receipts are e-mails sent to the. original-sender of the Registered 
message. The receipt 20 may contain: 

1 . an identifier for administrative- purposes. This identifier may be or may 
include reference to the sender's ID and/or the value of the Internet Message- 
ID of the sender's message as received by the system; 

2. the date and time at which the receipt was generated; 

3 . the quoted body of the original message together with the e-mail addresses of 
its intended recipients; 

4. the date and time at which the RPost Server received the message; 

5. a table for each destination listing: 

(i) the time at which the recipient's MTA received the message 
and/or the time at which the system received a DSN report from 
the recipient' s MTA; 

(ii) a Delivery Status of the message for that destination. The 
Delivery Status quoted in a Delivery Receipt is based upon the 
system's internal record of the destination's Delivery Status. They 
may be transcribed as follows: 
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• Deliveries to destinations whose status is FAILED or 
UNDELIVERABLE will be recorded in the receipt as 
"failed". 

• Deliveries to destinations whose status is DELIVERED 
or DELIVERED-AND-WAITING-FOR DSN will be 
recorded in the receipt as "delivered to mail server". 

• Deliveries to recipients whose status is DELIVERED- 
TO-MAILBOX will be recorded in the receipt as 
"delivered to mail box". 

The purpose of these reports is to accurately apprise the reader of 
the form of verification of delivery the system has been able to 
achieve. 

6. a list of the original attachments of the e-mail together with the separate 
message digests of those attachments; 

7. copies of the attachments to the original message, each original 
attachment being attached as an attachment to the receipt; 

8* transcripts, summaries, or abstractions of the transcripts of all of the 

SMTP dialogs involved in the delivery of the message to each destination; 

9. quotations from the bodies and the attachments of all received DSN 
reports including whatever details of delivery or disposition of the 
message that they might reveal; and 

1 0. any files that were returned to the system as attachments to DSN reports. 
All of these separate elements of the receipt may have their own message digests 

or digital signatures included within the receipt. Additionally, the receipt may include a 
single overall encrypted message digest or digital signature computed and appended as 
part of the receipt, thus providing a single message authentication code which could be 
used to authenticate all of the information contained within the receipt. Since the receipt 
itself and SMTP dialogs and DSN reports within the receipt contain timestamps, the 
receipt includes a non-forgeable record of the message recipient(s), the message content, 
and the time(s) and route(s) of delivery. 
MUA Notification Processing 
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MUA Notifications could be collected and incorporated within RPost Delivery 
receipts in the same manner as MTA DSNs. However, MTA notifications are typically 
issued by receiving MTAs within a few hours of delivery whereas MUA Notifications 
vail not be generated, if ever, until the recipient opens his MUA e-mail client and takes 
5 some action with respect to the received mail. For this reason, in this embodiment of the 
invention MUA notifications are collected separately from MTA notifications and 
reported in "RPost Reading Receipts" separate from RPost Delivery Receipts. 

MUA notifications elicited by message headers constructed in the manner 
described above will be returned to a common RPost address (e.g. 

10 "readreceipts@RPost.com") and each notification will contain- in the name field of its 
address- the address of the original sender of this message. Because this is the only 
information required to generate an RPost reading receipt in the manner described below, 
the system can deal with MUA notices whenever these notices may arrive and without 
any need to have stored any information about the original message in its databanks. 

15 MUA notices may report, among other things, that a message has been read by a 

recipient, that a message has been displayed on the recipient's terminal (whether or not 
read), that a message has been deleted without having been opened. There is no 
protocol-governed standard for the content or format of MUA messages. The system 
could be configured so as to examine the text of MUAs to interpret their reports in the 

20 same fashion as the system uses for MTA DSNs. However, in the current embodiment 
of the invention, MUAs are not evaluated or interpreted by the RPost server but are, 
instead, passed on to the sender for his own evaluation in a form that can be 
authenticated by RPost. To accomplish this the system will create an e-mail message 
styled as an "RPost Reading Notice" which may include, among other items: 

25 1 . subject line of the received MUA notice; 

2. the body of the received MUA notice quoted as the body of the Reading 
Notice; t , , , . , - . ... - 

3. the received MUA notice included as an attachment; 

4. any attachment(s) to the received MUA notice included as an 
30 attachment(s). 

5. message digests of the received MUA notice and of any attachment(s) to 
that notice; 

6. a date and time stamp; 
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7. an encrypted hash of at least items 5 and 6 providing an authenticatible 
date stamped digital signature for the document and all of its contents. 
Receipt Disposition 

In the case of the current embodiment of the invention, both RPost delivery 
receipts and Reading Notices are sent to the original sender of the registered message. 
Since these receipts are digitally signed with an encrypted hash, RPost can authenticate 
the information contained in these messages any time they are presented to RPost for this 
purpose, in the manner described below. This means that once it has transmitted a copy 
of the receipt to its sender (with instructions to the sender to retain the receipt for his 
records), RPost has no further_need to retain, any data concerning the message or its 
delivery and may expunge all such records from its system. Thus, RPost need not keep 
any copy of the original message or the receipt. This economy of archival memory gives 
the present invention an advantage over various prior art message authentication systems 
that required large amounts of data storage at the service provider side; 

In this case the burden of retaining receipt data falls on the original sender of the 
message. Alternatively .or additionally, third party verifier RPost may, perhaps for an 
additional fee, store a permanent copy of the receipt or of some or all receipt data. The 
receipt orpart(s) thereof may be kept on any suitable archival storage devices including 
magnetic tape, CD ROM, or other storage device types. Additionally or alternatively, 
RPost may return receipts or parts thereof to a storage system devoted to this purpose 
within the control of the sender or the sender's organization, 

As described above, RPost receipt information includes all of the data from the 
original sender's message and its attachments. There are circumstances in which users of 
the system might not wish to undertake the burden of retaining receipts in their records 
(e.g., out of fear of accidental data loss) but might also not wish to have the contents of 
their message in the hands of the RPost third party. Accordingly RPost might discard the 
contents of messages but store in its database only such information (e.g. sender, date of 
composition, message digests, destinations and Delivery Statuses) as might be required 
for RPost to authenticate and verify the delivery of a message when presented with a 
copy of the message retained by the sender. 
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Verification 

In the event that the originator of a message requires evidence at a later date that 
an e-mail was sent, delivered, and/or read, the originator presents the receipt(s) for the 
message to the operators of the system. 
5 For example, in order to prove that a particular message was sent from sender 10 

to recipient 18, sender 1 0 sends to RPost a copy of receipt 20 with a request to verify the 
information contained within the receipt. This could be done by sending the receipt to a 
predefined mailbox at RPost, e.g., verify@RPost.com. RPost then determines whether 
or not the receipt is a valid receipt. A receipt is a valid receipt if the digital signature 

10 matches the remainder of the receipt, and the message digests match the corresponding 
respective portions of the original message. Specifically, RPost performs the hash 
function on the various portions of the message including the message body, the 
attachments, and the overall message including the SMTP dialog and DSN reports, to 
produce one or more message digests corresponding to the purported message copy. 

15 RPost compares the message digests in the purported copy, including the overall 

message digest, with- the message digests which RPost has computed from the purported 
message copy. The overall message digest can be compared by either decrypting the 
overall message digest received as the digital signature in the purported receipt, or by 
encrypting the overall message digest which was calculated from the purported message 

20 copy. If the message digests including the digital signature match, then the receipt is an 
authentic RPost-generated receipt. Assuming that a good hash function was used and 
that the keys used in the cryptographic hash function and the digital signature encryption 
algorithm have not been divulged to others, it is virtually impossible that the receipt has 
been "forged" by the person presenting the receipt. That is, the receipt must have been a 

25 receipt that was generated by RPost, and therefore the message contained in the receipt, 
the to/from information, the date and time of delivery, the fact of successful delivery, the 
route by which the message traveled, and any DSN information contained within the 
receipt, must be a true copy of that information and is accurate. RPost can then provide 
authentication, verification, and confirmation of the information contained within the 

30 receipt. This confirmation can take the form of an e-mail confirmation, affidavit 

testimony from RPost employees familiar with the methods used by RPost, live sworn 

testimony in depositions and in court, and other forms of testimony. RPost can charge 

sender 10, recipient 1 8, or any other entity, fees for the various respective confirmation 
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services. RPost can also provide testimony or other confirmation with regard to the non- 
authenticity of a purported receipt. Testimony may be provided in accordance with 
Federal Rules of Evidence 901(9), 901(10), 803(6), 803(7), 1001-1004, 1006, 702-706, 
corresponding state rules of evidence, and other applicable rules. 
5 In sum, the system provides reliable evidence based on the testimony of a 

disinterested third party that a particular message having a particular content was sent, 
when it was sent, who sent it, who received it, when it was opened for reading, and when 
it was deleted. This evidence can be presented any time a dispute arises regarding the 
content and delivery of messages, as for example in contract formation, the timing of 
10 stock buy or sell orders, and many other applications. The- operators of the system can 
attest to the accuracy of the information contained in the receipt itself without the need 
for the operators to preserve any record or copy of the information contained in the 
receipt. 

A significant advantage of the system is that it can be used by existing MTJAs 
15 without any change thereto. Because all the computation, encryption, ESMTP 

interrogation and dialog, DSN report collection, and receipt compilation, are performed 
by the third party RPost server, none of these functions need to be implemented within 
any of the user's equipment. Thus, users can take advantage of the system quickly and 
easily. 

20 In the embodiment of the invention described above, the RPost Sever registers 

the delivery of all messages passing through it. Alternatively, an RPost server might 
register only those messages having certain destinations (e.g. external to an organization) 
or from certain senders (e.g. a customer relations group). Alternatively or additionally, 
the RPost server might register only those messages that had distinguishing characters or 

25 strings in the subject or body of the message. For example, the server might register 
_ only messages that the sender had included M (R)" in the subject of the message. All other 
messages might be delivered by the RPost Server or some other server function as an 
ordinary Internet MTA. 

In this embodiment, RPost can raise revenue in a variety of ways. For instance: 

30 RPost can charge message sender 10 or her organization a fee on a per-message basis, on 

a per-kilobyte basis, on a flat fee periodic basis such as monthly, or on a combination of 

the above. RPost can also charge fees for authenticating and verifying a receipt, with a 

schedule of charges depending on whether the verification sought is a simple return e- 
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mail, a written affidavit or declaration, sworn fact testimony in deposition or in court, or 
sworn expert testimony in deposition or in court. If the users opt to have RPost retain 
copies of the receipts, RPost can charge per item and /or per-kilobyte per month storage 
fees. 
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II- FLOW DIAGRAM FOR REGISTERING AN OUTGOING MESSAGE 

FIGS. 2A-2G constitute a flow chart showing an exemplary operation of the first 
embodiment of the system. Modifying this flow chart to apply to other embodiments is 
within the skill of one familiar with software and e-mail protocols. 

FIG 3 A, Pre-processing, illustrates the steps taken with a message before it will 
be transmitted by the Registering Server (the System). 

To register an e-mail message, in step 201 an originator/sender/user creates an e- 
mail message using any Internet Mail User Agent (MUA). Possible MUAs include: (1) 
client side e-mail programs; (2) server based e-mail programs; (3) web based e-mail 
services; and (4) HTML forms submitted through web pages. The message may contain 
attached files as described in the Requests for Comments (RFCs) 822, 2046, and 2047, 
which are hereby incorporated by reference. RFCs are a series of notes regarding the 
Internet that discuss many aspects of computer communication, focusing on networking 
protocols, procedures, programs, and concepts. 

In this embodiment, the system functions as the sender's outgoing mail server 
and hence the sender's message will be directly transferred to the RPost Server by the 
sender's MUA (step 202). 

In step 203, the system creates a copy of the original message to be stored for 
later processing. 

In step 204, the system creates a record in a database which may include such 
information as: the time at which the message was received by the server, the names and 
size(s) of the file attachment(s) of the message, the name (if known) of each destination 
of the message; the internet address of each destination; the time at which the message 
was delivered to the destination's MTA (initially this value is null) and a unit which 
records the Delivery Status of eachrdestination. 

In step 205, the Delivery Status of each destination is set to "UNSENT". 

In step 206, the system generates and stores a message digest or digital 
fingerprint generated from the message body. 

In step 207, the system generates and stores a hash or message digest for each 
attachment included in the message. 
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In ste£ 208, the system may create a modified copy of the original message. In 
this second copy (step 209), the original subject line of the message may be amended to 
indicate that this copy is registered (e.g. by pre-pending "Registered"). 

In step 210, a notice that the message is registered by the system together with 
5 links to the system's Word Wide Web site may be appended to the body of the message. 

In step 211, the e-mail headers may be added requesting reading notification in a 
variety of header formats recognized by various MUAs. The requests for notification 
direct the return notification to an address associated with the system: for example, 
" readreceipt(%RPost.com ". These headers will also include the address of the original 
1 0 sender of the message in the name field of the address to which the MUA notification 
should be sent. 

Preprocessing having been completed, the system will now transmit a copy of the 
message to each of its destinations as illustrated in FIG 2B. 

Fig 2B illustrates the steps required to transmit a registered message. As step 220 
15 indicates, the process requires a separate transmission for each recipient of the message. 

In step 221, the system changes the header field of its working copy of the 
message to show the message as being "FROM:" a sender whose name is the original 
sender of the message but whose address is an "RPost.com" address constructed from: 

a) a string used to identify returning MTA notifications (e.g. 
20 "RCPT"); 

b) a string which uniquely identifies the message being sent; 

c) a tag which uniquely identifies the destination this copy of the 
message is being- sent to. 

In step 222, using the domain name of the destination currently being sent to, the system 

25 does a Domain Name Server Mail exchange lookup to find the address of the MTA(s) 

responsible for collecting mail for addresses in this domain. 

In step 223, the system attempts to make a direct telnet connection to the MTA of 

the destination. If the connection fails, the system will try to make the connection again. 

Provided that the system has not exceed a maximum number of retries (227) for this 

30 destination, the system will try to remake the connection perhaps using another MX 

sever for the destination 5 s domain (228). 

If, after a maximum number of retries, the system cannot connect to an MTA for 

this destination, the system will, as in step 226, record this destination's Delivery Status 
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as "UNDELIVERABLE" and cease attempting to deliver this message to this 
destination. 

On connecting to the destination's MTA, the system will begin making a record 
of its (E)SMTP dialog with the MTA (225). 
5 In step 229, the system attempts to initiate an Extended SMTP (ESMTP) 

exchange with the destination MTA by issuing an "EHLO" greeting. 

If the destination's MTS supports ESMTP, the system will then (230) determine 
if the destination MTA supports the SMTP function VERIFY. If the MTA supports 
VERIFY, the system will attempt to detennine if the destination address is a valid 
1 0 address within the domain (231). 

If the address is not valid, then, as in step 232, the system will record the 
Delivery Status of this destination as 'TAILURE" and will cease attempting to deliver 
this message to this destination. 

If the address is valid or if the ESMTP server does not support VERIFY, the 
15 system will then_(233) detennine if the receiving MTA supports the ESMTP service 
DSN (Delivery Status Notification). 

If the MTA does support ESMTP DSN, the system will transmit the message 
with ESMTP requests to notify the nominal sender of the message of delivery success or 
failure (234). Having transmitted the message, the system will record the Delivery 
20 Status of this destination as cc DELIVERED-AND-WAITING-'FOR-DSN" (235). 

If the receiving MTA does not support Extended SMTP, the system will transmit 
the message using SMTP (236) and record the destination's status as "DELIVERED" 
(237). 

Having delivered the message, the system will then store the (E)SMTP dialog, 
25 recording the delivery in a manner in which it can later be recovered (238) and attempt to 
send the message to another destination. 

Having transmitted a message to its destination(s), the system must perform 
several functions in order to gather information about the message's disposition. Fig. 2C 
illustrates the process by which the system processes MTA Notifications returned by 
30 recipient MTAs. 

Because of the format used in the headers of sent messages illustrated in Fig 2B 
step 221, MTA message notifications will be delivered to a fictional local address at the 

server. The system will be able to detect these notifications by a string (e.g. "rcpt" 

31 



NSDOCID: <WO. 



0211025A2_I_> 



WO 02/11025 



PCT/US01/23565 



embedded in their addresses (241). By parsing the address, as illustrated in 242, the 
system can determine which message to which destination prompted the received 
notification. 

In step 243, the system scans the subject line and the body of received MTAs for phrases 
that indicate whether the MTA is reporting a successful delivery, a failed delivery,, or that 
the message has been relayed to another server. 

In the event that the process at step 243 reveals that the notification is reporting a 
successful delivery, the system will, as illustrated in step 245, change the Delivery Status 
of the relevant destination of the relevant message to "DELIVERED-TO-MAILBOX". 

If the system determines that the MTA notice is reporting a delivery failure, the 
system will (247) change the Delivery Status of the relevant destination of the relevant 
message to "FAILURE". 

In the event that the system determines that the MTA notification indicates that 
the message was relayed to another server, the system will, as illustrated in step 249, 
change the Delivery Status of the relevant destination of the relevant message to 
"RELAYED". 

Having processed the MTA Notification, the system will save this message and 
all of its attachments in such manner that they may be later recalled and used in 
construction of a receipt for this destination (250). 

From time to time, as illustrated in Fig. 2D, the system will examine the status of 
each message to determine if the system has recovered all of the MTA notifications it is 
likely to receive for each destination of message and may hence proceed to construct a 
receipt for the message. 

The system will examine the Delivery Status of each destination of the message. 
If any destination has the Delivery Status "UNSENT" then the processing of the 
message is not complete. (252). 

If the Delivery Status of a destination is "DELIVERED-AND-WAITIN.G-FQR- 
DSN", then the system will not regard the processing for this destination as complete 
unless, as is illustrated in step 254, the time since delivery of the message has exceeded 
the system's waiting period (e.g. 24 hrs.). 

If the Delivery Status of a destination is "DELIVERED", (257) then the system 
will regard the processing of this destination as complete provided (258) that a period of 
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time has elapsed which the operators of the system treat as sufficient to have received 
notice of delivery failure from the destination's MTA. (e.g. 2 hours). 

Any other destination Delivery Status (e.g. "FAILED", "UNDELIVER-ABLE", 
"DELIVERED TO MAILBOX") is treated as having completed processing. 

If processing of any of a message's destinations is not complete the system takes 
no action but moves to consider other messages in the system (step 255). 

However, as illustrated in step 259, if processing of every destination of the 
message is complete, the system will generate a Delivery Receipt for the message. 
As illustrated by way of example in FIG. 2E, the receipt may include: 

An identifier for administrative purposes as in block 271. This 
identifier may be or may include reference to the sender's ID and/or the 
value of the Internet Message-ID of the sender's message as received by 
the system. 

As in block 272, the quoted body of the original message 12 together 
with the e-mail addresses of its intended recipients may also be included. 
As in block 273, a table for each recipient listing may include: 

• the time at which the recipient's MTA received the message 
and/or the time at which the system received DSN from the 
recipient's MTA; 

• the Delivery Status report of the message for that destination, 
i.e., "Delivered to Mail Server", "Delivered to Mail Box", 
"Relayed", "Delivery Failure", "Undeliverable"; 

As in block 274, a list of the original attachments of the e-mail 
together with their separate hash values or message digests. 

As in block 275, transcripts or abstractions of the transcripts of all 
of the SMTP dialogs involved in the delivery of the message to each 
destination. 

As in block 276 3 quotations from the bodies and the attachments 
of all received DSNs including whatever details of delivery or disposition 
of the message that they might reveal. 

As in block 277, the system may attach to the receipt copies of all 
of the attachments of the original message, and, as in block 278, the 
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system may additionally attach files returned to the system as attachments 
to DSNs. 

In step 279, having generated the text of the receipt so far, the system then 
generates a first hash for the e-mail message and a second hash(es) for any attachments 
to the body of the receipt and calculates a digital signature for each of the hash(es) using 
an encryption key known only to the operators of the system. Encryption can employ, 
for example, the Data Encryption Standard described in Federal Information Processing 
Standard Publication 4-2 (HPS PUB 46-2), the Data Encryption Standard, National 
Institute of Standards and Technology, which is hereby incorporated by reference. 
Alternatively, other known or new methods of encrypting the hash value may be used. 

In step 280, the encrypted hash is then appended to the end of the message as the 
"document digital signature". 

In step 281, the receipt 20, now being complete, may be sent by e-mail to the 
sender with the advice that it be kept for the sender's records. In step 282, the system 
may now delete all copies of the original message, attachments, and DSNs. 
Alternatively, rather than sending the receipt to the sender, the system may store the 
receipt, or both the sender and system can store the receipt. 

Because MUA notifications are returned only at the option of the recipient and 
only when the recipient takes some action with respect to the received message, 
embodiments of the system may choose to treat these return messages differently than 
MTA notifications. 

FIG. 2F illustrates how these MUA notifications may be treated by the system. 
MUA notifications are solicited by. the system by including various headers in outgoing 
messages in the manner of Fig 2 A, step 211. These headers direct compliant MUAs to 
send notifications to a system address (eg. "readreciept@EPost.com") set aside for this 
purpose. The headers also use, in the "name" field of this return address, the e-mail 
address of the original sender of the message. Accordingly, in step 286, when MUA 
notifications are returned to readreceint@RPost.com the system can, by examining the 
address of the notification, determine the address to which a reading notification should 
be sent. 

Upon the arrival of a read receipt from a destination's MUA, the system, in step 
287, generates a reading receipt that contains the subject of the received MUA 
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notification as its subject and incorporates, in its message body, the body of the received 
MUA Notification. 

In step 288, the system attaches to the receipt any files that may accompany the 
MUA's receipt (typically these may include details of delivery or disposition and 
identifying references to the original e-mail.) 

In step 289, the system generates a hash for any files attached to the receipt and 
records this hash in the body of the receipt. 

In step 290, the system generates a hash for the body of the receipt and its 
attachments, encrypts this hash, and appends the result to the message as a "document 
digital signature". 

In step 291, the system sends the resulting receipt to the sender of the message. 
In step 292, having sent this receipt, the system may delete all internal records of the 
transaction. 
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III. RPOST AS SECONDARY MAIL SERVER EMBODIMENT 

FIG 3. is a system diagram of a second embodiment of the present invention 
wherein the RPost server does not serve as the user's primary MTA but rather works in 
collaboration with another MTA. In this embodiment, the sender may elect to register a 
5 particular outgoing message by including some form of flag in an outgoing message, 

message subject, or message addresses. For example, if and only if a sender includes the 
symbol "(R)" in the subject of the message the sender's MTA will direct the message to 
be transmitted through the RPost server to generate a receipt. 

In this embodiment the operators of RPost receive revenues from the operator of 
1 0 the sender' s MTA per message and/or per kilobyte transmitted. 

IV, CC TO RPOST EMBODIMENT 

FIG. 4 is a system diagram of a third embodiment in which a carbon copy ("cc") 
is sent to the RPost server. In this embodiment, the user or message sender 10 can use a 
standard MUA and standard MTA without modification. Message sender 10 composes 

1 5 the e-mail having- a message body and any number of attachments, and addresses it to 
message recipient 1 8, along with any carbon copies (cc's) and blind carbon copies 
(bee's) as desired. Additionally, message sender 10 addresses a cc to RPost. RPost 
server 14 tags the message as before, and sends the tagged message including 
attachments to the recipient's MTA 16 and any designated cc's. On receipt of such a 

20 copy RPost Server 14 may send an e-mail acknowledging receipt of the copy. 

Recipient 18 and other destinations of the message will now receive two versions 
of the same message; a first version of the message received directly from sender 10, 
and a second and tagged version which was forwarded from RPost. Once RPost receives 
confirmation from recipient MTA 16 that the tagged version of the message was 

25 successfully received by recipient MTA 1 6, RPost server 14 composes message receipt 
20 as before and sends the receipt to sender 10 for his records. 

Revenue can be generated by establishing accounts for message originating 
domains or individual message senders, and charging the users' accounts per message, 
per kilobyte, per month, or a combination of these. Revenue can also be generated for 

30 the placement of advertisements on receipts and from authentication and verification 
services as previously described. 
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V. WEBSITE EMBODIMENT 

FIG.5 is a system diagram of a fourth embodiment. In this embodiment, RPost 
server 14 is associated with a website at which a user composes messages. Message 
sender 10 visits the RPost Website and composes his message at the website by entering 
5 the desired "to", "cc", "bcc", "Subject", and message text information. Attachments can 
be added by using features available on standard browsers and web servers. In this 
embodiment, the sender must additionally provide an address to which the registration 
receipt may be sent. RPost server 14 sends the receipt to sender 10 through sender's 
MTA. 

10 Revenue can be generated by establishing accounts for message originating 

domains or individual message senders, and charging the users' accounts per message, 
per kilobyte, per month, or a combination of these. Revenue can also be generated for 
the placement of advertisements on receipts and from authentication and verification 
services as previously described. 

15 VI. WEB BASED MUA EMBODIMENT 

FIG. 6 is a system diagram of a fifth embodiment. In this embodiment, the 
RPost server 14 is associated with a web based Mail User Agent. In addition to allowing 
users to compose mail through a web browser, such an MUA provides subscribers with 
browser viewable mailboxes that display messages stored on the Web server site. 

20 Subscribers to such a service gain access to mail accounts with usernames and 

passwords. In this embodiment, message sender 10 visits the RPost Website, accesses a 
Web Based e-mail account by entering a username and password, and composes his 
message which is transported for delivery to RPost Server 14. Receipts generated by the 
RPost server are returned to a web based mailbox associated, with the subscriber's 

25 account. 

In addition to the revenue sources available in other embodiments, in this 
embodiment the operators can charge storage fees for receipts held in the web based 
mailbox. 

In all of these embodiments, the receipt may serve as evidence that: 
30 (1) the originator sent an e-mail message; 

(2) the message was sent at a certain time; 

(3) the e-mail was addressed to certain recipient(s); 
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(4) the e-mail was delivered to the e-mail mailbox of each of its 
intended recipient(s); 

(5) the e-mail was delivered at a certain time; 

(6) the e-mail was delivered by a certain network route; and 

(7) the e-mail message and its attachments had the specific content 
recorded in the receipt. 

Furthermore, the system under certain circumstances generates a separate receipt, 
which may be used as evidence that: 

(1) the e-mail was inspected through the recipient's Mail User Agent 
(MUA); and 

(2) the recipient took certain actions in response to the message, e.g., 
read or deleted.the e-mail, at a particular time. 

As with the other embodiments, this embodiment produces documented evidence 
which may be attested to and verified by the disinterested third party operators of the 
system of the delivery and integrity of an electronic message. In other words, the system 
can be thought of as transforming the e-mail to a registered e-mail that can later be used 
to prove that a particular e-mail message was sent, that it was successfully delivered, and 
wheruand-how. 

Should a dispute ever arise, the dispute can be resolved through the receipt 
generated by the system because the receipt is so encoded that the operators of the 
system can determine the authenticity of the receipt as the product of the system. 
Thereafter, operators of the system can attest to the accuracy of the information 
contained in an authentic receipt, relying only on information contained in the receipt 
itself and without the need for the operators to preserve any record or copy of the 
information contained in the receipt. 

In addition to these benefits, the receipts generated by the system may also be 
useful, as evidence of the existence and authorship of such materials as might be - 
transmitted through the system. Moreover, the system is easy to use, as the system can 
be used from any Internet e-mail client program/MUA, so that there is no additional 
software required. 
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FLOW DIAGR A M FOR VATJT) ATTNG A RECEIPT 

FIG. 7 is a flow diagram illustrating an exemplary method for validating a 
receipt. In the event that the sender of a message should require evidence that an e-mail 
was sent and delivered (and/or read) the sender presents the receipts) corresponding to 
the message to the operators of the system in step 700. The operators of the system then, 
in step 702, detach and decrypt the document digital signature appended to the receipt. 
In step 703, the operators generate a hash of the balance of the document, including 
attachments. 

In step 704, if the current hash value does not match the decrypted hash value, 
then the system generates a report stating that RPost cannot authenticate the receipt as an 
accurate record of the delivery or the contents of the message described in the receipt. 

If the decrypted hash is equivalent to the current hash of the message, the system 
can, as in step 706, warrant that the information contained in the body of the message is 
unchanged since the receipt passed through the system. If the original message 
contained no attachments, the system may now generate a report that warrants that the 
receipt is an accurate record of the message's contents and its delivery by the RPost 
Server. 

If the receipt reports that the original message contained attachments, then the 
receipt will also record the name and hash value of each attachment. In generating the 
receipt all attachments of the original message are attached unchanged to the receipt. 
Accordingly, the system will, for each such attached file, generate a hash of the attached 
file (708) and compare it to the hash value recorded in the body of the receipt (709). 

If the calculated hash value of a file matches the value included in the receipt, the 
system can warrant that the file attached to the receipt is identical to that attached to the 
message as originally delivered. If the hashes do not match, then the system will report 
that it cannot warrant that the file attached to the receipt is identical to tEi file attached to 
the original message. 

Having performed this calculation for each file attached to the original message, 
the system prepares a report which reports on the authenticity of the receipt and each of 
its attached files (7 10) or which reports the failure of validation (712). 
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Having completed its evaluation, the system will then append a copy of the 

* 

receipt and all of its attachments to the report it has generated and send it via e-mail to 
the return address of the user who submitted the report for validation. 

VTL Registering Inbound E-mails 

FIG, 8 is a system diagram illustrating another embodiment of the invention in 
which incoming e-mails are registered. In this embodiment, a message sender 60 sends 
an e-mail message 70. Sender's MTA 62 sends message 70 onto the Internet as usual. 
However, in this embodiment RPost contracts with service subscriber/recipient 68 to 
register incoming e-mails. According to the agreement, RPost is designated with 
Network Solutions, Inc. (NSI) or other domain name authority as the mail recipient (MX 
server) for recipient 68. This causes the Domain Name Service (DNS) request 
performed by the sender's MTA 62 to return the IP address of RPost as the IP address for 
the recipient, which in turn causes sender's MTA 62 to send the e-mail message to RPost 
server 64. RPost server 64 acts as an SMTP, POP, POPS or IMAP MTA (collectively, 
"POP mail server") for recipient 68. SMTP, POP and IMAP MTAs are governed by 
RFC 821, the SMTP protocol, RFC 1939 Post Office Protocol - Version 3 (which 
obsoleted RFC 1725), and RFC 2060 IMAP (Internet Message Access Protocol) Version 
4 rev 1 (which obsoleted RFC1730), which are hereby incorporated by reference. 

RPost Server 64 prepares a registered version 74 of the original message 70, and 
places this registered version 74 into recipient 68 's in-box instead of, or in addition to, 
the original message 70. The registered version may have all of the verification and 
informational features and options discussed earlier in connection with e-mails receipts. 
This information can include, but is not limited to: individual message digests for each of 
the message body and text, the to/from information, other header information, each 
attachment, an overall message digest and digital signature and message routing 
information and^tags. Registered version 74 of message 70 as shown in FIG. 6 includes 
the message' body including the header information, an attachment, separate message 
digests for each, and a digital signature or encrypted message digest. The hash functions 
and encryption are performed using private phrases or private keys known only to the 
operators of the system. The registered version 74 is made available to recipient 68 for 
inspection or downloading through the recipient's MUA. 
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RPost server can optionally send a confirming e-mail 72 to message sender 60. 
Confirmation message 72 can be a simple text message indicating that a message was 
received and registered. Confirmation message 72 could also include a message such as, 
"Your e-mail message was received on March 24, 2000 at 2:05 pan. The digital 
5 signature of the message was [128-bit digital signature]. For more information, visit our 
website at www.KPost.com." Alternatively, or additionally, confirmation message 72 
could include all of the information contained in the registered version 74. 

Thus, the system may provide to message recipient 68 a receipt 74 or other 
verifiable confirmation that: 
10 (1) the recipient received an e-mail message; 

(2) the message was received at a certain time; 

(3) the e-mail was addressed from a certain sender; 

(4) the the message purports to be delivered via a certain network route; and 

(5) the e-mail message and its attachments had a specific content. 
Accordingly, the system provides evidence, which may be attested to by the operators of 
the system, that particular electronic messages and documents were delivered to 
recipients having certain content and representing themselves as having come from 
certain senders. 

FIG. 9 is a flow chart illustrating one example of registering in-bound mail. In 
step 901, RPost server 64 receives a new e-mail message. In step 902, the system 
generates a hash/digital signature of the message's contents including the message's 
headers and attachments. Additionally, the system may generate a separate hash for each 
message attachment. In step 903, the. system encrypts the hash(es) using an encryption 
key known only to the operators of the system. In step 904, the resulting encrypted 
hash(es) is then appended to the body of the message. Then, in step 905, the modified 
message may be made available for inspection or download through the recipient's 
MUA. 

FIG. 10 is a flow chart of one example of vahdating a received registered e-mail 
message. In step 1 000, in the event that the recipient of a message should require 
evidence that an e-mail with a specific content was received at a particular time, the 
recipient can present a copy of the registered version 74 (FIG. 8) of e-mail message 70 to 
the operators of the system for verification. To verify the message, in step 1 001 the 
system detaches and decrypts the documenUIigital signature appended to the message. In 
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step 1002, the system generates a hash of the balance of the document, and one for each 
file attached to the message. In steps 1003 and 1004, the hashes are compared. If the 
document hash(es) matches the decrypted hash(es), then the message and its attachments 
must have passed through the system and have not been altered since their delivery to the 
recipient. 

Having determined that the e-mail is unaltered, the operators of the system can 
warrant that: 

(1) the e-mail was received by the system at a certain time; 

(2) the e-mail purported to arrive at the system via a certain Internet route; 

(3) the e-mail purported to be from a certain sender; and 

(4) the e-mail and its attachments were delivered with the specific content 
they currently contain. 

On the other hand, in step 1006, if the hash values do not match, then the operator cannot 
warrant that the e-mail is authentic, i.e., that the e-mail is an accurate version of an e- 
mail that was received by the system. 

FIG. 11 illustrates how the invention may be used by a business which utilizes 
electronic tools (an "e-business"). E-business 30 can utilize the system to register all 
incoming andoutgoing e-mail messages from its customers 34. In this case- the -system 
includes Post Office Protocol (POP) server 36 and Simple Mail Transfer Protocol 
(SMTP) server 38. For example, the e-business 30 can set up its website to e-mail forms 
to customers, and to forward queries and complaints 40 from customers 34. The 
registered queries, complaints, orders, offers to purchase, and other information 46 are 
sent to the e-business 30 by the system. Receipts are then provided to the customers 34 
via SMPT server 38. This way there is no question regarding whether or not the 
customer sent the communication and what it contained. Moreover, the e-business can 
set up a web site 32 through the RPost server so that every communication with the 
customers can be registered. In other words, through the web site form data orders 42 
and automated responses 44 can be registered through the system server; furthermore, 
any confirmation, collections notices, customer support, and special offers 48 sent by the 
e-business to customers 34 can be registered and the confirmation sent to the customer to 
eliminate arguments about what was ordered, when, or by whom. If desired, identical 
receipts can be provided to both the customers 34 and to e-business 30. Alternatively, 
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the functions of POP server 36 and SMTP server 38 may be combined in a single system 
server. 

POP is a protocol used to retrieve e-mail from an e-mail server. Many e-mail 
applications (sometimes called e-mail clients) use the POP protocol, although some can 
use the newer Internet Message Access Protocol (IMAP). One version of POP, called 
POP2, requires SMTP to send messages. A newer version, POP3, can be used with or 
without SMTP. SMTP is a protocol for sending e-mail messages between servers. 
Many e-mail systems that send e-mail over the Internet use SMTP to send messages 
from one server to another; the messages can then be retrieved with an e-mail client 
using either POP or IMAP. In addition, SMTP is generally used to send messages from 
a mail client to a mail server. E-mail servers may use a variety of protocols to 
communicate with the Internet. Commonly used protocols include SMTP, POP3 and 
IMAP4. Mail readers are at the opposite end of the server. Since mail servers receive 
messages via SMTP, e-mail readers send e-mail to a mail server using SMPT. Likewise, 
since mail servers send messages using POP3 and optionally IMAP4, mail readers 
receive messages from mail servers, by using the POP3or IMAP4 protocol. 

Although the above generally describes a system and method of verifying that an 
e-mail was sent and/or received, the present invention may apply to any electronic 
message that can be transmitted through a electronic message network or through any 
electronic gate. Electronic messages may include text, audio, video, graphics, data, and 
attachments of various file types. The methods and techniques taught herein can be 
programmed into servers and other computers, and computer programs implementing the 
invention can be written onto computer readable media including but not limited to CD 
ROMs, RAM, hard drives, and magnetic tape. E-mail registration services according to 
the present invention can be bundled with Internet service provider (ISP) services to 
provide a single provider ISP solution to corporate and other institutional clients. 
Implementing the above-described invention is within the skill of the ordinary 
practitioner of the software arts. 

Although the present invention has thus been described in detail with regard to 
the preferred embodiments and drawings thereof, it should be apparent to those skilled in 
the art that various adaptations and modifications of the present invention may be 
accomplished without departing from the spirit and the scope of the invention. 

Accordingly, it is to be understood that the detailed description and the accompanying 
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drawings as set forth hereinabove are not intended to limit the breadth of the present 
invention, which should be inferred only from the following claims and their 
appropriately construed legal equivalents. In the following claims, those claims which 
contain the words "means for" are intended to be interpreted in accordance with 35 
U.S.C. § 1 12, paragraph 6; those claims which do not include the words "means for" are 
intended to not be interpreted in accordance with 35 U.S.C. § 1 12, paragraph 6. 
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WHAT IS CLAIMED IS: 

1 • A method of documenting delivery and content of an electronic message, 
comprising: 

receiving an electronic message from a message sender, the electronic message 
having at least one designated electronic delivery address associated therewith; 
transmitting the electronic message to said designated address; 
receiving electronic delivery status notification information regarding delivery of 
7 the electronic message to the designated address; 

computing a message authentication code corresponding to at least the message; 
assembling a copy of at least a portion of the . message, the electronic delivery 
status notification information, and the message authentication code, said assemblage 

1 1 defining an electronic receipt; and 

12 transmitting the receipt to a storage means. 



1 

2 
3 
4 
5 
6 



8 
9 
10 



1 2. The method of claim 1 wherein transmitting the receipt to a storage 

2 comprises transmitting the receipt to the message sender. 



4 



means 



1 3. The onethod of claim 2 further comprising the step of discarding the original 

2 message after transmitting the electronic receipt to the sender. 



4. The method of claim 1 further comprising at a later time: 



receiving a purported receipt and a purported message authentication code 
3 associated therewith: 



detentiining that the purported message authentication code corresponds to the 
5 message; and 

providing sworn testimony verifying content and delivery of the message to the 



6 

7 addressee 



i 5. The method of claim 1 wherein said sworn testimony is provided for a fee. 

1 6. The method of claim 1 wherein the message authentication code corresponds 

2 additionally to delivery status and delivery time information. 
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1 7. The method of claim 1 wherein the step of computing an authentication code 

2 comprises: 

3 computing a first message digest corresponding to at least a body of the message; 

4 computing a second message digest corresponding to an attachment to the 

5 message; 

6 computing an overall message digest corresponding to said first and said second 

7 message digests; and 

8 encrypting said overall message digest to create a digital fingerprint. 

1 8. The method of claim 1 wherein computing a message authentication code 

2 comprises: 

3 using a secure hashing algorithm, computing a message digest corresponding to 

4 at least the message and the electronic delivery status notification information. 

1 9. The method of claim 1 wherein said transmitting step comprises: 

2 estabhshing a direct telnet connection with an e-mail server associated with the 

3 destination address; and 

4 transmitting the message directly to said e-mail server. 

1 10. The method of claim 1 further comprising the step of tagging the message to 

2 indicate that it has been registered with a third party prior to said step of transmitting the 

3 message to said designated address. 

1 11. The method of claim 1 , wherein: 

2 said step of receiving an electronic message comprises receiving the electronic 

3 message as an e-mail cc; and 

4 the electronic delivery address is determined by examining a delivery address 

5 designated within a header associated with the message. 

1 12. A method of providing proof regarding the delivery and content of an 

2 electronic message, comprising: 

3 receiving from a sender across a computer network an electronic message, said 

4 message having a delivery address associated therewith; 
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5 sending said message electronically to a destination corresponding to said 

6 delivery address; 

receiving delivery status notification information associated with said message 

8 and said delivery address; 

9 providing to said sender: 

10 a substantial copy of said message; 

1 1 said delivery status notification information; and 

1 2 a me ssage digest computed substantially from said message copy and said 

1 3 delivery status notification information; and 
at a future date receiving electronically said electronic receipt from said sender, 

verifying that said message digest corresponds to said message, and verifying that said 
message was received by an electronic message handler associated with said delivery 



14 
15 
16 

17 address 



1 13. An electronic message server programmed to implement the method of 

2 claim 12. 

1 14. A computer readable memory capable of causing a computer to implement 

2 the method of claim 12. 



9 
10 
11 
12 
13 



1 15. The method of claim 12 further comprising: 

2 sending said message to a plurality of additional destinations corresponding to 

3 additional delivery addresses associated with the message; 

4 receiving additional delivery status notification information associated with said 

5 message and said additional delivery addresses; and 

6 sending a delivery verification message to the sender, the delivery verification 

7 message including: 

8 a list of all of said addresses; and 
said delivery status notification information respectively corresponding to 

all of said addresses, said delivery status notification information including for 
each addressee a listing of whether or not delivery was successful and, if delivery 
was successful, the date and time at which delivery occurred. 
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1 16. The method of claim 12 wherein said computer network is the Internet and 

2 said electronic message is an e-mail message. 

1 17. The method of claim 12 wherein the step of sending said message 

2 electronically to a destination corresponding to said delivery address comprises: 

3 establishing direct communication to a recipient electronic message server 

4 corresponding to said destination; and 

5 sending said electronic message directly to said recipient electronic message 

6 server; and 

7 verifying that said recipient electronic message server reported receiving said 

8 electronic message without errors. 

1 18. The method of claim 17 wherein said direct communication comprises a 

2 telnet connection across the Internet. 

1 19. The method of claim 12, wherein said message digest is encrypted. 

1 20. The method of claim 1 2, further comprising: 

2 for a fee, providing sworn testimony verifying content of, said message and 

3 receipt thereof at said delivery address. 

1 21 . The method of claim 12, wherein said message digest includes: 

2 a first message digest computed according to a body of said message; and 

3 a second message digest computed according to an attachment to said message. 

1 22. The method of claim 12, wherein said message digest comprises a first 

2 message digest computed according to a body of said message and at least one electronic 

3 attachment to said message. 

1 23. A method of verifying delivery of an electronic message to a plurality of 

2 destinations, comprising: 

3 receiving an e-mail message, said e-mail message including a plurality of 

4 destination e-mail addresses associated therewith and a message originator address 

5 associated therewith; 
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6 forwarding said message to said plurality of addresses; 

providing a report to said message originator, the report listing whether the 

8 message was successfully transmitted to a computer associated with each respective 

9 destination address, and if the message was successfully transmitted, the date and time at 
which the e-mail was successfully received by the computer associated with the 

1 1 respective destination address. 



10 



1 24. The method of claim 23 wherein the message is received from the sender 

2 across the Internet; the report is sent to the sender across the Internet, and wherein the 

3 method further comprises: 

4 charging a fee to said message originator. 



1 

2 



25. A method of verifying delivery of an electronic message, comprising: 
in a computer system, receiving an electronic message from a message sender for 

3 routing to a destination address; 

4 establishing communication with an electronic message server associated with" 

5 the destination address, said server defining a destination server; 

6 querying said destination server to determine whether said destination server 

7 supports delivery status notification (DSN) functionality; 

8 receiving a response to said query, said query and response together defining an 

9 SMTP dialog; 

10 requesting delivery status notification information from said destination server 

1 1 according to results of said SMTP dialog; 
transmitting said electronic message to said destination address; 
receiving DSN information from said destination server with respect to delivery 

14 of said electronic message; and 

15 providing to said message sender at least a portion of said SMTP dialog, and at 

1 6 least a portion of said DSN information.. 

1 26. The method of claim 25, wherein the providing step includes composing an 

2 electronic receipt, said electronic receipt including: 

3 a copy of said electronic message; 
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4 at least a portion of said SMTP dialog and at least a portion of said DSN 

5 information; and 

6 a message authentication code corresponding to content of said receipt. 

1 27. A method of verifying content of a received electronic message, comprising: 

2 registering a designated server as the recipient for messages addressed to e-mail 

3 addresses at a plurality of top level domains; 

4 m receiving an electronic message addressed to a first e-mail address within said 

5 plurality of top level domains; 

6 generating a message authentication code corresponding to content of said 

7 received message and delivery information associated with said message; 

8 providing the message and the message authentication code to a recipient 

9 associated with said first e-mail address; 

10 at a later time, verifying that said message digest corresponds to said message 

1 1 and delivery information. 

1 28. The method of claim 27 wherein said message authentication code comprises 

2 an encrypted message digest. 

1 29. The method of claim 27 wherein said providing comprises POP mail service. 

1 30. The method of claim 27 wherein said message authentication code and said 

2 message are combined into a single delivered message provided to said designated 

3 addressee. 

1 31. A method of verifying delivery and reading of an electronic message, 

2 comprising: 

3 receiving an electronic message across the Internet from a message sender, said 

4 message including an electronic destination address; 

5 forwarding said message to a destination server associated with said destination 

6 address; 

7 requesting delivery status notification from said destination server; 
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receiving confirmation from said destination server that said message was 
received; 

sending to the message sender at least one receipt, said at least one receipt 
including: 

delivery information, said delivery information including the time at 
which the message was received; 

read notification information regarding when a user at said destination 
address opened said electronic message for reading; and 

at least one message authentication code corresponding to the message, 
the delivery information, and the read notification information. 

32. The method of claim 3 1 wherein said at least one receipt comprises: 

a first receipt, said first receipt comprising said delivery information and a first 
message authentication code associated therewith; and 

a second receipt, said second receipt comprising said read notification 
information and a second message authentication code associated therewith. 

33 . A method of verifying that an electronic message was sent, comprising: 

generating an electronic message for a recipient from information received from a 
message originator; 

sending the electronic message to the recipient; 

generating a message digest corresponding to content of the electronic message; 
encrypting the message digest; and 

sending the electronic message and the encrypted digest to the message 
originator. 

34. The method according to claim 33, further comprising: 

tracking delivery status notification of the message; 

appending the delivery status notification to the electronic message; and 

storing the appended delivery status notification for later verification if needed. 
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1 35. The method according to claim 33, wherein the electronic message is sent 

2 to the recipient through a computer network. 

1 36. The method according to claim 35, wherein the computer network is a 

2 wide area network. 

1 37. The method according to claim 35, wherein the computer network is the 

2 Internet. 

1 38. A method of later proving that an electronic message was previously sent 

2 to a recipient, comprising: 

3 receiving from an independent party an electronic message, and- further receiving 

4 an address corresponding to an intended recipient of the message; 

5 creating a validation code corresponding to the message; 

6 transmitting the validation code to a storage means for storage thereat; and 

7 sending the message to the recipient. 
8 

1 39. The method of claim 38 wherein said storage means comprises said 

2 independent party. 

1 40. The method according to claim 38 wherein said storage means comprises 

2 an on-site memory device. 

1 41 . The method according to claim 38 wherein said validation code is a 

2 message digest. 

1 42. The method according to claim 41 further comprising: 

2 encrypting the message digest; 

3 creating a receipt, the receipt including the encrypted message digest; and 

4 forwarding the receipt to the independent party for later verification if needed. 

1 43. A method of establishing whether a message was electronically received 

2 by a recipient, comprising: 
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3 ~ providing a message to be dispatched electronically along with a recipient's 
, 4 address from a sender; 

5 dispatching the message electronically to the recipient's address; 

6 upon receiving a delivery status of the message, generating a receipt, the receipt 

7 including: 

8 a copy of the message; 

9 a digital signature associated with the message; and 

10 the delivery status for the message; and 

1 1 providing the receipt to the sender, for later establishing that the message was 

12 electronically received by the recipient. 

44. The method of claim 43 wherein the digital signature is an encrypted 
message digest. 

1 45. The method of claim 43, wherein the message is an e-mail message. 

1 46. The method of claim 43, wherein the digital signature is a message digest 

2 corresponding to the message. 

1 47. The method of claim 43, wherein the message is dispatched via the 

2 Internet. 

1 - 4S - ^ met h°d of claim 43, wherein the message is provided by logging onto 

2 a registrant's server to create an e-mail message for the recipient. 

1 49. The method of claim 43, wherein the status of the message is a Delivery 

2 Status Notification. 

1 50. The method of claim 43, wherein tracking for the delivery status of the 

2 message dispatched is done for a period of up to about 24 hours. 

1 51. The method of claim 43, wherein tracking for the delivery status of the 

2 message occurs for more than about 24 hours, and the receipt records that delivery of the 

3 message is a delivery failure. 
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1 52. The method of claim 43, wherein the receipt further includes the time that 

2 the message was received at the recipient's address. 

1 53. The method of claim 43 , wherein the message includes an attached file, 

2 and wherein the method further comprises: 

3 creating a message digest associated with the attached file; and 

4 encrypting the message digest; 

5 and wherein said dispatching step includes dispatching the message including the 

6 attached file. 

1 54. The method of claim 43, further including: 

2 sending the receipt to the sender of the message. 

1 55. The method of claim 43, further comprising: 

2 requesting a reading receipt from the recipient; and 

3 if the request for a reading receipt is responded to by the recipient, generating a 

4 second digital signature corresponding to the contents of the reading receipt and sending 

5 the second digital signature to the sender. 

1 56. A method of proving that an electronic message sent to a recipient was read, 

2 comprising: 

3 receiving an electronic message along with a recipient's address; 

4 calculating a message digest corresponding to the electronic message; 

5 dispatching the electronic message electronically to the recipient's address; 

6 requesting a reading notification; 

7 upon receiving the reading notification, generating at least one reading receipt, 

8 the at least one reading receipt including: 

9 a copy of the message; 

10 a first message digest for the corresponding electronic message; and 

1 1 a second message digest for the reading notification from the recipient; 

12 and 
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1 3 providing the reading receipt for later verification that said message was received 

14 by the recipient. 

1 57. The method of claim 56 wherein the electronic message is provided by 

2 logging onto a registrant's server to create an e-mail message for the recipient by a 

3 sender. 

1 58. The method of claim 57, further including: 

2 sending the reading receipt to the sender of the electronic message. 
59. The method of claim 56, further including: 

appending to the reading receipt any files accompanying the reading receipt; and 
generating respective message digests for any of the accompanying files. 



1 60. A method of validating the integrity of a purported copy of an electronic 

2 message, comprising: 



receivmg said purported electronic message copy, said purported copy including 

4 a digital signature and a transmission history associated therewith; 

5 decrypting the digital signature; 
generating a message digest based on content of the purported copy; and 

validating the purported copy by comparing the decrypted digital signature and 
8 the message digest to determine whether the two match. 

61. The method according to claim 60, further comprising: 

if requested, providing sworn testimony verifying the content of the electronic 
message. 

62. A method of registering an inbound electronic message, comprising: 

generating a message digest corresponding to an inbound electronic message 
being sent to a recipient's address; 

encrypting the message digest to create a digital signature; 
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5 appending the message digest to the contents of the inbound electronic message 

6 ' to create a receipt; 

7 transmitting the electronic message to the recipient address; and 

8 sending the receipt to an archival storage means. 



1 63. The method according to claim 62 wherein the electronic message is an e- 

2 mail. 



1 64. A method of registering an e-mail, comprising: 

2 generating a message digest for content corresponding to the e-mail; 

3 encrypting the message digest; 

4 appending-the encrypted message digest to the content of the e-mail to create a 

5 receipt; 

6 sending the e-mail; and 

7 transmitting the receipt to a storage means for storage thereat. 

1 65. A method of documenting delivery of an e-mail message comprising: 

2 receiving an e-mail message from a sender; 



3 forwarding the message to at least one designated recipient; 

4 recording delivery information associated with the forwarding of the message to 

5 each designated recipient; 

6 computing a message digest corresponding to the said message and delivery 

7 information; 

8 transmitting the message digest to the sender; 

9 discarding the message; and 

10 at a later time, examining said message, said delivery information, and said 

1 1 message digest, and providing third party verification services attesting that said message 

12 was sent to the designated recipient at the time indicated within the delivery information. 
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1 66. The method of claim 65, further comprising: 

2 performing the steps recited in claim VK1 for each of a plurality of unrelated 

3 entities, thereby providing independent third party e-mail authentication and verification 

4 services for said entities. 

1 67. The method of claim 65 further comprising: 

2 programming a message transport agent associated with said sender to redirect 

3 outgoing e-mail message originally addressed to said designated recipient, to a 

4 designated third party, and to alter said message to include said designated recipient's e- 
. 5 mail address; 

6 and wherein said third party performs said forwarding, recording, computing, and 

7 transmitting steps. 

1 68. The method of claim 67 further comprising: 

2 providing a flag which a message sender can set in order to designate a particular 

3 outgoing message as a message to be registered. 

1 69. The-method~ofxlaim 65 further comprising: 

2 advising the designated recipient that the message has been registered with a third 

3 party verification service. 

1 70. The method of claim 65, further comprising: 

2 charging the message sender a fee, said fee selected from- the group comprising of 

3 a monthly fee, another periodic fee, a fee based on amount of data registered, and a per- 

4 message fee. 

1 71 . The method of claim 65, wherein said attesting is performed for a fee. 
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1 72. An electronic receipt for delivery of an electronic message, said receipt 

2 comprising: 

3 a body of an electronic message; 

4 delivery information pertaining to a date and time that the electronic message 

5 body was delivered to a computer associated with a designated addressee; and 

6 a message authentication code computed from said message body and said 

7 delivery information, said message authentication code being computed by an 

8 independent entity. 

1 73. A method of providing electronic message registration services to the public, 

2 comprising: 

3 providing a worldwide web site at which a user can input a message and 

4 designate a recipient by entering the recipient's electronic address; 

5 receiving-the message and the recipient's address via said website; 

6 forwarding the message to the recipient's electronic address; and 

7 providing^eciire-documentation to the user pertaining to : 

8 the message content; and 

9 the date and time at which the message was forwarded to the recipient's 
10 electronic address. 

1 74. The method of claim 73 further comprising: 

2 receiving delivery confirmation from a computer associated with said recipient's 

3 electronic address, and including said delivery confirmation as part of said secure 
4_ documentation. 

1 75. The method of claim 74 further comprising: 

2 receiving reading receipt information regarding when the designated recipient 

3 opened the electronic message for reading, and including said reading receipt 

4 information as part of said secure documentation. 
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1 76. A method of providing e-mail message documentation services, comprising: 

2 receiving an e-mail message from a message sender; 

3 creating a copy of the message and appending to the message copy a tag advising 

4 that the message has been registered with a third party e-mail registration service; 

5 forwarding the tagged copy to a designated addressee; and 

6 providing secure documentation to the message sender regarding content of the 

7 message and delivery status information associated therewith. 

1 77. A method of documenting delivery and content of an electronic message 

2 comprising: 

3 recording electronic message protocol exchanges that effect delivery of 

4 the message to a destination mail transport authority (MTA); 

5 assembling a copy of at least a first portion of the message, the protocol 

6 exchanges, an authentication code corresponding to at least a second portion of 

7 the message, said assemblage defining an electronic receipt; and 

8 transmitting the receipt to a storage means. 



1 



78. The method of claim 77 wherein said protocol exchanges comprise simple 



2 mail transport protocol (SMTP) exchanges. 



1 79. The method of claim 77 further comprising: 

2 assigning a fictitious return address to the message in such a way that a 

3 receiving MTA will return delivery status notification (DSN) with sufficient 

4 information so as to enable determination of which message and which 

5 destination the DSN concerns merely by analysis of the DSN' s return address and 

6 without otherwise relying on content of said message. 

1 80. The method of claim 77 further comprising: 

2 scanning subject lines and bodies of a return MTA notification to 

3 determine, by the presence of indicative phrases, whether the MTA notification 
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4 reports a successful delivery, a failed delivery, or the relay of the message to a 

5 non extended simple mail transport protocol (ESMTP) complaint mailer. 

1 81. The method of claim 77 further comprising: 

2 assembling and delivering a delivery report which, for each successful 

3 delivery of the message indicates whether the system is only able to verify on the 

4 basis of said recorded protocol exchanges, delivery of said message to a 

5 destination's mail server or, alternatively, whether the system is able to verify on 

6 the basis of an MTA notification, delivery of the message to an electronic 

7 mailbox corresponding to the destination. 

1 82. A method of tracking delivering of a particular electronic message 

2 comprising: 

3 assigning a fictitious return address to the message, the fictitious return 

4 address containing sufficient information to identify the original message; and 

5 requesting message delivery status notification so as to cause a device 

6 which receives the message to report delivery status information to the fictitious 

7 return address. 

1 83. The method of claim 82 wherein: 

said fictitious return address contains sufficient information to identify 
content of the message. 
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84. A method of transmitting a message through the internet from a sender to a 
recipient through a server displaced from the recipient, including the steps at the server of: 

receiving the message at the server from the sender, 

transmitting, through the internet from the server to an agent of the recipient, the 
5 message, an identification and an internet address of the server and the identity of the 
sender of the message, 

receiving from the agent at the server through the internet the identity of the agent 
and an indication of the receipt by the agent of the message and the identification and 
internet address of the server and the identify of the sender and the digital fingerprint of the 
10 message, and 

sending to the sender from the server through the internet a copy of the message 
and the information received by the server from the agent 

85. A method as set forth in claim 84 wherein 

the indication received by the server through the internet from the agent includes an 
identification of the agent and any transfer agent through whom the message has passed 
between the server and the agent. 

86. A method as set forth in claim 84 wherein 
the server identifies any attachment to the message and wherein 
the identity of the attachment received by the server through the internet from the 

agent and wherein 

the server sends to the sender through the internet a copy of the attachment 
received from the agent. 

87. A method as set forth in claim 84 wherein 

a digital fingerprint of the message is provided at the server by a plurality ofdigits 
in a unique sequence and is sent by the server to the sender. 



61 

<WO 021 1 025A2_L> 



WO 02/11025 



PCT/USO 1/23565 



88. A method as set forth in claim 84 wherein 

the server creates a message digest of the message and encrypts the message digest 
and sends the encrypted message digest to the sender through the internet with the 
message, the identification and e-mail address of the server and the identity of the sender. 

5 

89. A method as set forth in claim 84 wherein 

the message passes from the server to the agent through at least one mail transfer 
agent and wherein 

the agent includes, in the information transmitted to the server, the identity and 
10 address of the at least one mail transfer agent and wherein 

the server includes in the information transmitted to the sender the identity of the at 
least one mail transfer agent received by the server from the agent. 

90. A method of transmitting a message through the internet from a sender to a 

1 5 recipient through a server displaced from the recipient, including the steps at the server of: 
receiving the message at the server from the sender, 

transmitting from the server through the internet to an agent the message and the 
identity and internet address of the server and an indication representing the identity of the 
sender, 

20 receiving at the server from the agent a handshaking and delivery history of the 

message from the server to the agent, and 

transmitting from the server to the sender through the internet the message, a 
digital signature, including a digital fingerprint, of the message and the handshaking and 
delivery history of the message received from the agent. 

25 

91 . A method as set forth in claim 90 wherein 

the server retains a copy of th^digital signature of the message and the 
handshaking and delivery history of the message, but not a copy of the message unless 
requested to do so by the sender, after the server transmits to the sender through the 
30 internet the message, the digital signature of the message and the handshaking and delivery 
history of the message. 
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92. A method as set forth in claim 90 wherein 

the server retains a copy, except for the message, of the information received by the 
server from the agent and sent to the sender and wherein 

when the sender wishes to authenticate that the message was sent by the server to 
the agent, the server matches the information, except for the message, sent by the server to 
the sender relating to the message with the information retained by the server relating to 
the message. 

93. A method as set forth in claim 90 wherein 
the message includes an attachment and wherein 
the server receives the attachment from the sender and wherein 
the server transmits the attachment to the agent at the same time that the sender 

transmits the message to the agent and wherein 

the server receives from the agent the attachment at the same time that it receives 
the message and the handshaking and delivery history of the message from the agent and 
wherein 

the server transmits the attachment and a digital signature, including a digital 
fingerprint, of the attachment to the sender at the same time that it transmits the digital 
signature of the message to the sender. 

94. A method as set forth in claim 90 wherein 

the message is transmitted from the sender to the agent in an individual one of a 
variety of recognized header formats and wherein 

the server receives from the agent the digital signature of the message and the 
handshaking and delivery history of the message with the header formed in the individual 
one of the variety of recognized header formats. 

95. A method as set forth in claim 90 wherein 

the server requests a delivery status notification from the agent relating to the 
30 message when it transmits the message to the agent and wherein 
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the server receives the delivery status notification from the agent when it receives 
the digital signature of the message from the agent. 

96. A method as set forth in claim 90, including the step at the agent of: 

5 indicating the delivery status of the message from the server in the transmittal from 

the agent to the server through the internet. 

97. A method as set forth in claim 93, including the steps at the sender of: 
receiving from the server through the internet, at the same time as the receipt of a 

10 copy of the message to the agent from the server, a copy of any attachment to the message 
and a digital signature, including a digital fingerprint, of the attachment, and 

providing for a transmittal from the agent to the server through the internet of the 
digital signature, including the digital fingerprint, of the attachment at the same time as the 
transmittal of the message from the agent to the server. 

15 

98. In a method of transmitting a message through the internet from a sender to a 
recipient through a server displaced from the recipient, the steps at the server of: 

receiving the message at the server from the sender, 
generating a hash constituting a synopsis of the message in coded form, 
20 encrypting the hash with a particular encryption code to generate a digital 

fingerprint of the message, and 

transmitting the message and the digital fingerprint of the message through the 
internet to the sender. 

- 5 99. In a method as set forth in claim 98, the steps at the server of: 

generating, for any attachment to the message, a hash constituting a synopsis of the 
attachment in coded form, 

encrypting the hash with a particular encryption code to generate a digital '' 
fingerprint of the attachment, and 
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transmitting the attachment and the digital fingerprint of the attachment to the 
sender through the internet at the same time that the message and the digital fingerprint of 
the message are transmitted from the server to the sender through the internet. 

5 1 00. In a method as set forth in claim 98, the steps at the server of: 

transmitting to an agent for the recipient through the internet the identity of the 
sender and the identity and internet address of the server at the same time that the server 
transports to the agent the message through the internet; and 

receiving from the agent through the internet, the name of the sender, the name and 
1 0 internet address of the server and the identity and internet address of the agent. 

101. In a method as set forth in claim 99, the steps at the server of: 
transmitting to an agent for the recipient through the internet the identity of the 
sender and the identity and internet address of the server at the same time that the server 
1 5 transports to the agent the message through the internet; 

receiving from the agent through the internet the name of the sender, the name and 
internet address of the server and the identity and internet address of the agent; and 

receiving from the agent through the internet the digital fingerprint of the 
attachment at the same time that the server receives the digital fingerprint of the message 
20 through the internet. 

102. In a method as set forth in claim 100, the steps at the server of: 
storing at the server the digital fingerprint of the message, the name of the sender, 
the identity and internet address of the server and the identity and internet address of the 
25 agent, and 

transmitting to the sender for storage by the sender the digital fingerprint of the 
message, the name of the sender, the identity and internet-address of the server and the 
identity and internet address of the agent. 
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103. In a method as set forth in claim 101, the steps of: 

storing at the server a digital fingerprint of the message, the name of the sender, the 
identity and internet address of the server and the identity and internet address of the agent, 

transmitting at the server to the sender for storage by the sender a digital fingerprint 
5 of the message, the name of the sender, the identity and internet address of the server and 
the identity and internet address of the agent, 

storing at the server a digital fingerprint of the attachment, and 

transmitting at the server through the internet to the sender, for storage by the 
sender, the digital fingerprint of the attachment, as received by the server from the agent, at 
10 the same time that the server transmits to the sender through the internet the digital 
fingerprint of the message and the identity of the sender and the identity and e-mail 
address of the server and the identity and internet address of the agent, all as received by 
the server from the agent. 

15 1 04. In a method as set forth in claim 1 02, the step of: 

sending at the server to the sender through the internet the message received by the 
server from the sender with an appendage of the digital fingerprint of the message for 
storage by the sender. 

105. In a method as set forth in claim 103, the step of: 

sending at the server to the sender through the internet the message received by the 
server from the sender with an appendage of the digital fingerprint of the message for 
storage by the sender. 

1 06. In a method of transmitting a message through the internet from a sender to 
an agent for the recipient through a server displaced from the agent, the steps at the server 
of: 

receiving the message at the server from the sender, 

generating a hash constituting a synopsis of the message of the message in encoded 

form, 
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encrypting the hash with a particular encryption code to generate a digital 
fingerprint of the message, 

transmitting the message and the identity of the sender and the identity and internet 
address of the server through the internet from the server to the agent, 
5 receiving at the server through the internet any transmission through the internet 

from the agent concerning the message from the sender, and 

determining the transmission received by the server from the agent, or from the 
lack of any reception by the server through the internet from the mail transport authority, 
the delivery status of the transmission by the server to the agent and the delivery status of 
10 any delivery of the message by the agent to the recipient. 

107. In a method as set forth in claim 106, the steps at the server of: 
periodically examining the delivery status of the message transmitted to the agent 

and the delivery status of any delivery of the message by the agent to the recipient, and 
1 5 transmitting the message and the digital fingerprint of the message and the identity 

of the sender and the identity and internet address of the server through the internet to the 
sender with an indication of the delivery of the message to the agent when the server 
determines from the periodic examination that the message has been delivered to the said 
transport agent. 

20 

1 08. A method of transmitting a message through the internet from a sender to an 
agent for a recipient through a server displaced from the agent, including the steps at the 
server of: 

receiving the message at the server, 
25 providing a digital fingerprint of the message, 

transmitting through the internet to an agent of the recipient the message and the 
identity of the sender and the identity and the internet address of the server, 

receiving the identity and internet address of the agent and the identity of the 
sender and the identity and internet address of the server, and 
30 providing to the sender the information received by the server from the agent and 

the digital fingerprint of the message. 
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109. A method as set forth in claim 108, including the steps at the server of: 
providing to the sender the message at the same time as the provision of the digital 

fingerprint of the message to the sender, and 

retaining the information provided to the sender but discarding the message 
5 provided to the sender. 

1 1 0. A method as set forth in claim 108, including the steps at the server of: 
providing an indication of the date and time of the reception of the identity and 

internet address of the agent and the identity of the sender and the identity and the internet 
10 address of the server from the agent, and 

providing to the sender the indication of the date and time of the reception of the 
digital fingerprint from the agent. 

1 1 1 . A method as set forth in claim 108, including the steps at the server of: 

1 5 receiving from the sender a copy of the message provided by the server and a copy 

of the digital fingerprint of the message and the identity and internet address of the agent 
and the identity of the sender and the identity and internet address of the server, and 
comparing the digital fingerprint of the message and the identity and internet 
address of the agent and the identity of the sender and the identity and internet address of 

20 the server, all as received from the sender, and the identity and internet address of the 
agent and the identity of the sender and the identity and internet address of the recipient, 
all as provided by the server, and the digital fingerprint of the message at the server, and 

authenticating the message received from the sender on the basis of the comparison 
provided at the server. 

25 

1 12. A method as set forth in claim 108, including the steps at the server of: 
forming at the server the digital fingerprint of the message by providing a hash of 
the message and then 

encrypting the hash of the message. 

30 



68 



0211025A2_1_> 



WO 02/11025 



PCT/USO 1/23565 



113. A method as set forth in claim 108, including the steps at the server of: 
providing a digital fingerprint of an attachment to the message, 
transmitting to the agent the attachment at the same time as the transmittal of the 

message, and 

5 transmitting to the sender the digital fingerprint of the attachment at the same time 

as the transmission of the digital fingerprint of the message. 

1 14. A method as set forth in claim 1 12, including the steps at the server of: 
providing an indication of the date and time of the reception of the message from 

10 the agent, and 

providing to the sender the indication of the date and time of providing to the 
server the digital fingerprint of the message from the agent at the time of providing to the 
sender the digital fingerprint of the message, 

providing to the sender the message at the same time as the provision of the digital 
1 5 fingerprint of the message to the sender, and 

retaining the information provided to the sender but discarding the message 
provided to the sender, 

providing a digital fingerprint of an attachment to the message, 

transmitting to the agent the attachment at the same time as the transmittal of the 
20 message, 

transmitting to the sender the digital fingerprint of the attachment at the same time 
as the transmission of the digital fingerprint of the message, 

receiving from the sender a copy of the message provided to the sender and a copy 
of the digital fingerprint of the message and the identity and internet address of the agent 
25 and the identity of the sender and the identity and internet address of the server, 

comparing the digital fingerprint of the message and the identity and internet 
address of the agent and the identity of the sender and the identity and internet address of 
the server, all as received from the sender, and the digital fingerprint of the message and 
the identity and internet address of the agent and the identity of the sender and the identity 
30 and internet address of the recipient, all as provided by the server, and 
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authenticating the message received from the sender on the basis of the comparison 
provided by the server. . 

115. In a method of transmitting a message through the internet from a sender to 
5 an agent for a recipient through a server displaced from the recipient, the steps at the server 

of: 

providing at the server a digital fingerprint of the message, 
storing at the server the digital fingerprint of the message, and 
transmitting to the sender the message and the digital fingerprint of the message for 
10 storage by the sender. 

116. In a method as set forth in claim 1 1 5 , the step at the server of: 
discarding the message after the transmission of the message and the digital 

fingerprint of the message to the sender. 

15 

117. In a method as set forth in claim 1 16 the steps at the server of: 
receiving from the sender copies of the message and the digital fingerprint of the 

message, 

comparing the digital fingerprint of the message from the sender and the stored 
20 digital fingerprint of the message, and 

authenticating the message on the basis of the results of the comparison. 

118. In a method as set forth in claim 115, 

providing at the server, at the same time as the provision of the digital fingerprint 
of the message at the server, the identity of the sender and the identity and internet address 
of the server and the address and internet address of the mail transport agency, all as 
received by the server from the agent, 

storing at the server the information received by the server from the agent, and * 
transmitting to the sender the identity of the sender, the identity and internet 
address of the server and the identity and internet address of the agent, all as received by 
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the server from the agent, at the same time as the transmission of the message and the 
digital fingerprint of the message to the sender. 

119. In a method as set forth in claim 1 15, the steps at the server of: 
5 storing at the server the digital fingerprint of the attachment of the message, and 

transmitting to the sender, at the same time as the transmission of the message and 
the digital fingerprint of the message, the attachment and the digital fingerprint of the 
attachment as received by the server. 

10 120. In a method as set forth in claim 1 1 9, the steps at the server of: 

receiving from the sender copies of the message and the attachment and the digital 
fingerprints of the message and the attachment, and 

respectively comparing the digital fingerprints of the message and the attachment 
and the stored digital fingerprints of the message and the attachment to authenticate the 
1 5 message and the attachment on the basis of this comparison. 

121 . In a method as set forth in claim 1 19, the steps at the server of 
storing at the server, at the same time as the provision of the digital fingerprints of 
the message and the attachment at the server, the identity of the sender and the identity and 
20 internet address of the server and the address and internet address of the agent, all as 
received by the server from the agent, 

transmitting to the sender the identity of the sender, the identity and internet 
address of the server, the identity of the sender, and the identity and internet address of the 
agent, all as received by the server from the agent, at the same time as the transmission of 
25 the message and the attachment and the digital fingerprint of the message and the 
attachment to the sender. 

122. A method of transmitting a message through the internet from a sender to an 
agent for a recipient through a server displaced from the agent, including the steps of 
30 providing the message from the sender at the server, 
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providing at the server a digital fingerprint of the message and the identity of the 
sender and the identity and internet address of the server, 

transmitting to the agent the message and the identity of the sender and the identity 
and the internet address of the server, 
5 providing at the agent an indication of the status of the reception at the agent of the 

transmittal from the server to the agent of the message and the identity of the sender and 
the identity and interest address of the server, and 

transmitting to the server from the agent the identity and internet address of the 
agent and the status of the reception at the agent of the message and the identity of the 
1 0 sender and the identity and internet address of the server. 

123 . A method as set forth in claim 122 5 including the steps of: 
providing at the server a digital fingerprint of an attachment to the message, 
transmitting the attachment to the agent at the same time as the transmittal of the 

15 message to the agent, 

providing at the agent the status of the reception of the attachment at the same time 
as the provision at the agent of the status of the reception of the message, and 

transmitting to the server from the agent the status of the reception of the 
attachment at the same time as the transmittal to the server from the agent of the status of 
20 the reception of the message. 

124. A method as set forth in claim 122 wherein 

the digital fingerprint of the message includes a digital digest of the message and 
an encryption of the digital digest. 

25 

125. A method as set forth in claim 122 wherein 

the agent includes in the transmission to fee server the date and time of the 
transmission by the agent to the server. 
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126. A method as set forth in claim 122 wherein 

the server transmits to the sender the message and the digital fingerprint of the 
message and the identity of the sender and the identity and internet address of the server 
and the identity and internet address of the agent and the status at the agent of the reception 
5 at the agent of the message. 

127. A method as set forth in claim 122 wherein 

the delivery status of the message at the agent includes at least one of the 
following: (a) DELIVERED, (b) RELAYED, (c) DELIVERED-AND-WAITING FOR 
10 DELIVERY STATUS NOTIFICATION (DSN), (d) DELIVERED-TO-MAILBOX, and 
(e) FAILED, UNDELIVERABLE. 

128. A method as set forth in claim 122 wherein 

the digital fingerprint of the message includes a digital digest of the message and 
15 an encryption of the digital digest, 

the agent includes the date and time of the transmission by the agent to the server, 

and 

the server transmits to the sender the message and the digital fingerprint of the 
message and the identity of the sender and the identity and internet address of the server 
20 and the identity and internet address of the agent and the status at the agent of the reception 
at the agent of the message and the digital, fingerprint of the message, 

the delivery status of the message at the agent includes at least one of the 
following: (a) DELIVERED, (b) RELAYED, (c) DELIVERED- AND-WAITING FOR 
DELIVERY STATUS NOTIFICATION (DSN), (d) DELIVERED-TO-MAILBOX, and 
25 (e) FAILED, UNDELIVERABLE. 

— 129. A method as set forth in claim 128, including the steps of: 

providing at the server a digital fingerprint of an attachment to the message, 
transmitting the attachment to the message to the agent at the same time as the 
30 transmittal of the message to the agent, 
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providing at the agent the status of the reception of the attachment at the same time 
' as the provision at the agent of the status of the reception of the message, and 

transmitting to the server from the agent the status of the reception of the 
attachment at the same time as the transmittal to the server from the agent of the status of 
5 the reception of the message. 

130. A method of transmitting a message through the internet from a sender to an 
agent for a recipient through a server displaced from the agent, including the steps at the 
server of: 

1 0 providing at the server a digital fingerprint of the message and the identity of the 

sender and the identity and internet address of the server, 

transmitting to the agent the message and the identity of the sender and the identity 
and internet address of the server, 

receiving from the agent the identity of the sender and the identity and internet 
1 5 address of the server and the identity and internet address of the agent and an indication of 
the status of the reception of the message at the agent, and 

transmitting to the sender the message and the information received by the server 
from the agent relating to the message. 

20 13 1 . A method as set forth in claim 130, including the steps at the server of: 

providing at the server a digital fingerprint of an attachment to the message, 
transmitting to the agent the attachment at the same time that the message is 
transported to the agent, 

receiving from the agent the status of the reception at the agent of the attachment at 
25 the same time that the server receives from the agent the status of the reception at the agent 
of the message, and 

transmitting to the sender the attachment and the information received by the server 
from the agent relating to the attachment at the same time that the server transmits to the 
sender the message and the information received by the server from the agent relating to 
30 the message. 
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132. A method as set forth in claim 130 wherein 

the delivery status of the message at the agent includes at least one of the 
following: (a) DELIVERED, (b) RELAYED, (c) DELIVERED-AND- WAITING FOR 
DELIVERY STATUS NOTIFICATION (DSN), (d) DELIVERED-TO-MAILBOX, and 
5 (e) FAILED, UNDELI VERAB LE . 

133. A method as set forth in claim 130 wherein 

the server receives from the agent the date and time of the transmission by the 
agent to the server of the status of the reception of the message at the agent and wherein 
10 the server transmits to the sender the date and time of the transmission by the agent 

of the status of the reception by the agent of the message at the same time that the server 
transmits to the sender the status of the reception by the agent of the message. 

134. A method as set forth in claim 133 wherein 

15 the server also transmits to the sender the date and time of the transmission to the 

sender of the status of the reception by the agent of the message. 

135. A method as set forth in claim 134 wherein 

the server does not store the message after it transmits the message to the sender. 

20 

136. A method as set forth in claim 134 wherein 

the server transmits to the sender the identity of the sender and the identity and 
internet address of the server at the same time that it transmits the message and the digital 
fingerprint of the message to the sender and wherein 
25 the server stores the identity of the sender and the identity and the internet address 

of the server and the digital fingerprint of the message and wherein 

the server compares the stored identity of the sender and the-identity and the 
internet address of the server, all as stored by the server, and the identity of the sender and 
the identity and the internet address of the server, all as received by the sender, to 
30 authenticate the message transmitted from the server to the sender. 
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137. A method as set forth in claim 134 wherein 

the server transmits to the sender the identity and internet address of the agent and 
the status of the reception of the message, all as received by the server from the agent, and 
the digital fingerprint of the message and wherein 
5 the server stores the identity and internet address of the agent and the status of the 

reception of the message received by the agent, all as received by the server from the agent 
and the digital fingerprint of the message, and wherein 

the server compares the stored identity and internet address of the agent and the 
status of the reception of the message and the digital fingerprint of the message with the 
10 identity and internet address of the agent and the status of the reception of the message and 
the digital fingerprint of the message all as received by the sender from the server, to 
authenticate the message transmitted from the server to the sender. 

138. A method as set forth in claim 136 wherein 

15 the server does not store the message after it transmits the message to the sender 

and wherein 

the server transmits to the sender the identity and internet address of the agent and 
the status of the reception of the message received by the agent, all as received by the 
server from the agent, and the digital fingerprint of the message, and wherein 
20 the server stores the identity and internet address of the agent and the status of the 

reception of the message and the digital fingerprint of the message received by the agent, 
all as received by the server from the agent, and the digital fingerprint of the message and 
wherein 

the server compares the stored identity and internet address of the agent and the 
25 status of the reception of the message and the digital fingerprint of the message with the 
identity and internet address of the agent and the status of the reception of the message 
and the digital fingerprint of the message, all as received by the sender from the server, to 
authenticate the message transmitted from the sender to the server. 
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139. A method of authenticating a message transmitted through the internet from a 
sender to a recipient through a server displaced from the recipient, including the steps at 
the server of: 

transmitting to the sender the message and a digital fingerprint of the message, and 
a status of the reception of the message by an agent for the recipient, 

storing the digital fingerprint of the message at the server and the status of the 
reception of the message by the agent, 

receiving from the sender the digital fingerprint of the message and the status of the 
reception of the message by the agent, and 

comparing the stored digital fingerprint of the message and the digital fmgerprint 
of the message as received by the server from the sender to authenticate the message 
transmitted from the server to the sender. 



140. A method as set forth in claim 139 wherein 

1 5 the server stores the information transmitted by the server relating to the status of 

the reception of the message and the digital fingerprint of the message but does not store 

the message and wherein 

the server compares the information stored by the server, and the information 

provided by the sender, relating to the status of the reception by the agent of the message, 
20 and the digital fingerprint of the message, to authenticate the message transmitted by the 

server to the sender. 

141 . A method as set forth in claim 139 wherein 

the server transmits to the sender the identity of the sender and the identity and 
25 internet address of the server, all as transmitted by the agent to the server and wherein 

the server stores the identity of the sender and the identity and internet address of 
the server, all as transmitted by the agent to the server and wherein 

the server compares the information stored by the server, and the information 
provided by the sender, relating to the identity of the sender and the identity and 
30 information address of the server to authenticate the message transmitted by the server to 
the sender. 
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142. A method of authenticating a message transmitted through the internet from 
a sender to an agent for a recipient through a server displaced from the agent, including the 
steps of: 

transmitting to the sender the message and a digital fingerprint of the message and 
5 a status of a reception by an agent for the recipient of the message, 

storing the digital fingerprint of the message at the server, and 

comparing the stored digital fingerprint of the message and the digital fingerprint 

of the message transmitted to the sender to authenticate the message transmitted from the 

server to the sender. 

10 

143. The method as set forth in claim 142 wherein 

the server does not store the message after it transmits the message to the sender. 

144. A method as set forth in claim 142 wherein 

15 the server transmits to the sender the identity of the sender and the identity and 

internet address of the server at the same time that it transmits the message and the digital 
fingerprint of the message to the sender and wherein 

the server stores the identity of the sender and the identity and the internet address 
of the server at the same time that it transmits the message and the digital fingerprint of the 
20 message to the sender and wherein 

the server receives from the sender the identity of the sender and the identity and 
internet address of the server and wherein 

the server compares the identity of the sender and the identity and the internet 
address of the server, all as received by the server from the sender, with the stored identity 
25 of the sender and the stored internet address of the server to authenticate the message 
transmitted from the server to the sender. 



145. A method of transmitting a message through the internet from a sender to 
an agent for a recipient through a server displaced from the agent, including the steps at the 
30 server of, 

receiving the message from the sender, 
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transmitting to the agent the message and a fictitious return address identifying the 
message, the sender and the recipient, 

receiving from the agent the fictitious return address identifying the message, the 
sender and the recipient, and 
5 identifying the message transmitted from the server to the agent and received by 

the server from the agent and identifying the message, the sender and the recipient. 

146. A method as set forth in claim 145 wherein 

the server transmits to the sender the fictitious return address received by the server 
1 0 from the agent and identifying the message, the sender and the recipient for return by the 
sender and wherein 

the server stores the fictitious return address received by the server from the agent 
and identifying the message, the sender and the recipient. 

15 1 47. A method as set forth in claim 1 46 wherein 

the server transmits the message to the sender at the time that it transmits to the 
sender the fictitious return address received by the server from the agent and identifying 
the message, the sender and the recipient and wherein 

the server does not retain the message after it transmits the message to the sender. 

20 

148. A method as set forth in claim 145 wherein 

the recipient is one of a plurality of recipients receiving the message from the 
server and wherein 

the fictitious return address identifies the recipient from among the recipients in the 

25 group. 

149. A method as set fortlrin claim 145 wherein 
the message has an attachment and wherein 

the fictitious return address also identifies the attachment to the message. 

30 
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150. A method as set forth in claim 146 wherein 

the server transmits the niessage to the sender at the time that it transmits to the 
sender the fictitious return address received by the server from the agent and identifying 
the message, the sender and the recipient and wherein 
5 the server does not retain the message after it transmits the message to the sender 

and wherein 

the recipient is one of a plurality of recipients receiving the message from the 
server and wherein 

the fictitious return address identifies the recipient from among the recipients in the 
10 group and wherein 

the message has an attachment and wherein 

the fictitious return address also identifies the attachment to the message. 



151. In a method of identifying a sender's message transmitted from a server to 
15 an agent for a recipient, the steps at the server of: 

transmitting to the sender a fictitious return address received by the server from the 
agent and identifying the message, the sender and the receiver, 

storing in the server the fictitious return address transmitted by the server to the 
sender, and 

20 receiving from the sender the fictitious return address transmitted by the server to 

the sender, and 

comparing the fictitious return address provided by the sender and the fictitious 
return address stored in the server to authenticate the message provided by the sender. 

25 152. In a method as set forth in claim 151 wherein, 

the server transmits to the sender the message at the same time that it transmits the 
fictitious return address to the sender and wherein 

the server does not retain the message after it transmits the message to the sender. 
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153. In a method as set forth in claim 151 wherein 

the recipient is an individual one of a plurality of recipients receiving the message 
from the server and wherein 

the fictitious return address identifies the individual one of the recipients in the 
5 group receiving the message. 

154. In a method as set forth in claim 151 wherein 
the message has an attachment and wherein 

the fictitious return address identifies the attachment to the message. 

10 

155. In a method as set forth in claim 152 wherein 

the recipient is an individual one of a plurality of recipients receiving the message 
from the server and wherein 

the fictitious return address identifies the individual one of the recipients in the 
1 5 group receiving the message and wherein 

the message has an attachment and wherein 

the fictitious return address identifies the attachment to the message. 

156. A method of transmitting a message through the internet from a sender to 
20 an agent for a recipient through a server displaced from the recipient, including the steps at 

the agent of: 

receiving from the server though the internet the message and a digital signature, of 
the message and the identity of the sender and the name and internet address of the server, 
and 

25 providing for a transmittal to the server through the internet the digital signature of 

the message and the identity of the sender and the name and internet address of the internet 
and the name and internet address of the agent. 

1 57. A method as set forth in claim 156, including the step at the agent of: 
30 indicating in the transmittal from the agent to the internet whether or not the 

message has been delivered by the agent to the recipient. 
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158. A method as set forth in claim 156, including the step at the agent of: 
indicating in the transmittal from the agent to the internet that the message and the 

digital signature, of the message and the identity of the sender and the name and internet 
address of the server have been sent by the agent to another agent for delivery to the 
5 recipient. 

159. A method of providing a delivery at a first server of an electronic message 
from the first server to a destination address, including the steps of: 

receiving at the first server an electronic message from a message sender for 
0 routing to the destination address, 

transmitting the electronic message to a destination server for the destination 
address and transactions between the first server and the destination server receiving the 
message via a protocol selected from a group consisting of an SMTP and an ESMTP 
protocol 

5 recording at the first server the transactions between the first server and the 

destination server in the selected one of the protocols. 

1 60. A method as set forth in claim 159, including the steps of: 

including in the transaction between the first server and the destination server the 
0 identity of the sender, the identity and internet address of the first server and the identity 
and internet address of the destination server. 

161. A method as set forth in claim 159, including the steps of: 
providing transactions between the first server and the sender, 

5 including, in the transactions between the first server and the sender, a digital 

fingerprint of the electronic message from the message sender. 

1 62. A method as set forth in claim 159, including the step of: 

recording, in the transactions between the first server and the destination server, the 
0 time for the sending of the message from the first server to the destination server and the 
time for the receipt of the message by the destination server. 
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163. A method as set forth in claim 160, including the steps of: 
providing transactions between the first server : and the sender, and 
including, in the transactions between the first server and the sender, a digital 

fingerprint of the electronic message from the sender, and 
5 recording, in the transactions between the first server and the destination server, the 

time for the sending of the message from the first server to the destination server and the 
time for the receipt of the message by the destination server. 

164. A method as set forth in claim 1 59, including the step of: 

10 including in the transaction between the first server and the destination server the 

status of the delivery of the message from the destination server to the recipient. 

165. A method as set forthin claim 159, including the step of: 

receiving at the first server a delivery status notification relating to the status of the 
15 delivery of the message to the destination server and the delivery of the message from the 
destination server to the recipient. 

166. In a method of verifying at a first server a delivery of an electronic message 
to a destination server for a recipient, the steps of: 

20 transmitting the electronic message from the first server to the destination server 

through a transaction between the first server and the destination server via a protocol 
selected from the group consisting of an SMTP protocol and an ESMTP protocol, 
recording at the first server the transactions between the first server and the 
destination server in the selected one of the protocols, and 

25 transmitting to the sender the transactions between the first server and the 

destination server in the selected one of the protocols. 

1 67. In a method as set forth in claim 1 66, the step of: 

transmitting from the first server to the sender a copy of the message at the time of 
30 the transaction of the first server and the destination server in the selected one of the 
protocols. 
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168. In a method as set forth in claim 166,-the step of: 

destroying the message at the first server after the transmission of the copy of the 
message in the selected one of the protocols by the first server to the destination server. 

5 1 69. In a method as set forth in claim 1 66, the steps of: 

recording at the first server a digital fingerprint of the message, and 
transmitting the digital fingerprint of the message from the first server to the sender 
at the time of the transmission of the selected one of the protocols from the first server to 
the sender. 

10 

170. In a method as set forth in claim 169, the steps of: 

transmitting from the first server to the sender a copy of the message at the time of 
the transaction of the first server and the destination server in the selected one of the 
protocols, and 

1 5 destroying the message at the first server after the transmission of the copy of the 

message in the selected one of the protocols by the first server to the destination server. 



171 . In a method as set forth in claim 170, the step of: 

20 transmitting between the first server and the destination server the name of the . 

sender, the name and address of the first server and the name and address of the 
destination server and the time of the receipt of the message by the first server. 

172. In a method as set forth in claim 166, the step of: 

25 receiving at the first server a delivery status notification indicating the status of the 

delivery of the message from the first server to the destination server and the time of the 
transmission of the delivery status notification by the destination server to the first server. 

1 73 . In a method of verifying at a first server a message received by the first 
30 server from a sender and transmitted by the first server to a destination server for a 

recipient, the steps of: 
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recording at the first server transactions between the first server and the destination 
server relating to the message from the sender, the transactions between the first server and 
the destination server being provided via a protocol selected from the group consisting of a 
SMTP protocol and an ESMTP protocol, 
5 transmitting from the first server to the sender the message and the transactions 

between the first server and the destination server via the selected one of the SMTP 
protocol and the ESMTP protocol, and 

comparing at the first server the recorded transactions and the transactions 
previously transmitted from the first server to the sender and subsequently provided by the 
1 0 sender to the first server, thereby to authenticate the message transmitted by the first server 
to the sender when there is a correspondence in the comparison. 

174. In a method as set forth in claim 173, the step of: 
transmitting with the message from the first server to the sender a digital 

1 5 fingerprint of the message at the same time that the first server transmits to the sender the 
transactions between the first server and the destination server via the selected one of the 
SMTP protocol and the ESMTP protocol. 

175. In a method as set forth in claim 170, the step of: 

20 removing the message from the first server when the first server transmits to the 

sender the message and the transaction between the first server and the destination server 
via the selected one of the SMTP protocol and the ESMTP protocol. 

1 76. In a method as set forth in claim 1 73, the steps of: 

25 recording at the first server the indication of the name of the sender, the name and 

address of the first server and the name and address of the destination server at the time of 
the recording at the first server of the transactions between the first server-and the 
destination server via the protocol selected from the group consisting of the SMTP 
protocol and the ESMTP protocol, and 

30 transmitting from the first server to the sender the name of the sender, the name 

and address of the first server and the name and address of the destination server at the 
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time of the transmission from the first server to the destination server of the transaction 
between the first server and the destination server via the protocol selected from the group 
consisting of the SMTP protocol and the ESMTP protocol, 

the comparison at the first server including a comparison of the name of the sender, 
5 the name and address of the first server and the name and address of the destination server 
as received by the first server from the sender and as recorded by the first server. 

177. In a method as set forth in claim 175, the steps of 

recording at the first server the digital fingerprint of the message and transactions 
10 between the first server and the destination server relating to the message from the sender, 
the transactions between the first server and the destination server being provided via a 
protocol selected from the group consisting of an SMTP protocol and an ESMTP protocol, 

transmitting from the first server to. the sender the message and the digital 
fingerprint of the message and the transactions between the first server and the destination 
15 server via the selected one of the SMTP protocol and the ESMTP protocol, 

transmitting the message from the first server to the sender and a digital fingerprint 
of the message at the same time that the first server transmits to the sender the transactions 
' between the first server and the destination server via the selected one of the SMTP 
protocol and the ESMTP protocol, and 
20 comparing at the first server the recorded digital fingerprints and recorded 

transactions with the digital fingerprint and the transactions previously transmitted from 
the first server to the sender and subsequently provided by the sender to the first server, 
thereby to authenticate the message transmitted by the first server to the sender when there 
is an correspondence in the comparison. 

25 

178. In a method as set forth in claim 173, the step of: 

recording at the first server an indication of the identity of the sender, the identity 
and the address of the first server and the identity and address of the destination server at 
the same time that the transactions between the first server and the destination address are 
30 recorded at the first server, 
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transmitting from the first server to the sender the identity of the sender, the 
identity and address of the first server and the identity and address of the destination server 
at the time that the message and the transactions between the first server and the 
destination server are transmitted from the first server to the sender, and 
5 comparing at the first server the identity of the sender, the identity and address of 

the first server and the identity and address of the destination server, all as transmitted to 
the sender and as recorded in the first server, at the same time that the other comparisons 
are made, thereby to authenticate the message transmitted by the first server to the sender 
when there is a correspondence in the comparison. 

10 

179. A method of verifying delivery at a first server of an electronic message to a 
destination server for a recipient, including the steps of: 

receiving at the first server an electronic message from a message sender for 
routing to the destination server, 
15 establishing at the first server a communication with the destination server, 

transmitting from the first server the electronic message to the destination server 
with a protocol transaction via a protocol selected from a group consisting of an SMTP 
protocol and an ESMTP protocol, 

recording at the first server the protocol transactions between the first server and 
20 the destination server relating to the message, 

transmitting from the first server to the sender the message and the protocol 
transactions between the first server and the destination server, 

providing at the first server a comparison of at least a particular portion of the 
transactions in the selected one of the protocols as proof of delivery of the message by the 
25 first server to the destination server, the comparison being provided between the 

transaction protocol recorded at the first server and the transaction protocol received by the 
sender from the server. 

1 80. A method as set forth in claim 178 wherein 

30 the at least particular portion of the transactions provided in the selected protocol to 

the sender is thereafter provided by the sender to the first server, and 
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the at least particular portion provided in the selected protocol by the sender to the 
first server is compared in the first server with the at least particular portion recorded in the 
selected protocol at the first server to determine whether the message received by the 
sender is authentic. 

5 

181. A method as set forth in claim 178 wherein 

a digital fingerprint is made of the message at the first server and wherein 
the digital fingerprint is recorded at the first server with the protocol transactions 
and wherein 

10 the digital fingerprint is transmitted from the first server to the sender with the 

message and the protocol transactions between the first server and the destination server 
and wherein 

the digital fingerprint is provided by the sender to the first server with the at least 
particular portion of the transactions in the selected protocol. 

15 

1 82. A method as set forth in claim 1 80 wherein 

the digital fingerprint and the at least particular portion of the transactions provided 
in the selected protocol to the sender are thereafter provided by the sender to the first 
server and wherein the digital fingerprint and the at least particular portion provided in 
20 the selected protocol by the sender to the first server are compared in the first server with 
the digital fingerprint and the at least particular portion recorded in the selected protocol at 
the first server to determine whether the message received by the sender is authentic. 

183. A method of verifying at a first server the delivery of an electronic message 
25 from the first server to a destination server for a destination address including the steps of: 

receiving at the first server an electronic message from a message sender for 
routing to the destination server, 

transmitting to the destination server for the destination address the electronic 
message and transactions between the first server and the destination server relating to the 
30 electronic message via a protocol ^elected from the group consisting of an SMTP protocol 
and an ESMTP protocol, 
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recording at the first server the transactions between the first server and the 
destination server via the protocol selected from the group consisting of the SMTP 
protocol and the ESMTP protocol, 

transmitting to the sender the transactions between the first server and the 
5 destination server in the selected one of the protocols, and 

comparing at the first server the recorded transactions and the transactions 
previously transmitted from the first server to the sender and subsequently provided by the 
sender to the first server, thereby to authenticate the message transmitted by the first server 
to the sender when there is an identity in the comparison. 
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2/18 FI6.2A 



TO REGISTER AN EMAIL BY 
AN ORIGINATOR (e.g. "JOHN 
SMITH A T EMAIL ADDRESS 
jsmith@adomain. com ") 




ORIGINATOR CREATES AN EMAIL 
MESSAGE USING ANY INTERNET MAIL 
USER AGENT(MUA)(NOTE THE 
MESSAGE MA Y HA VE MUL TIPLE 
DESTINATIONS AND ATTACHMENTS) 



■202 



THE REGISTRA TION SYSTEM (RS), 
ACTING AS THE SENDERS MTA 
RECEIVES A COPY OF EMAIL 



•203 



RS WILL CREATE A COPY OF THE 
ORIGINAL MESSAGE TO BE STORED 
UNTIL THE REGISTRATION PROCESS 
IS COMPLETE 



RS CREA TES A DA TABASE RECORD 
WHICH INCLUDED: THE TIME AT 
WHICH THE MESSAGE WAS 
RECEIVED. THE NAMES AND SIZES 
OF THE ATTACHMENTS OF THE 
MESSAGE. THE NAME AND 
ADDRESS OF EACH DESTINA TION OF 
THE MESSAGE. THE TIME AT 
WHICH THE MESSAGE WAS 
DELIVERED TO THE DESTINATIONS 
MTA. THE DELIVERY STA TUS OF 
EACH DESTINATION 



■205 



RS SETS THE DELIVERY STATUS OF 
EACH DESTINATION TO "UNSENT" 



■206 



RS GENERA TES AND STORES 
MESSAGE DIGEST (HASH) OF THE | 
BODY OF THE MESSAGE. 



i r 



207 



RS GENERA TES AND STORES A 
HASH FOR EACH FILE ATTACHED 
TO THE MESSAGE 



208 



RS CREATES A SECOND COPY TO 
MODIFY THE ORIGINAL MESSAGE 



ZL 



209 



THE ORIGINAL SUBJECT LINE OF THE 
MESSAGE IS AMENDED TO INDICATE 
THA T THE COPY IS REGISTERED(e.g. 
BY PRE-PENDING "(REGISTERED") 



210 



A NOTICE THAT THE MESSAGE IS 
REGISTERED BY THE RS, TOGETHER 
WITH LINKS TO THE RSS www SITE 
ARE APPENDED TO THE BODY OF THE 
MESSAGE. 



ZL 



211 



EMAIL HEADERS ARE ADDED 
REQUESTING A MAIL USER 
AGENT(MUA) READING NOTIFICATION 
IN A VARIETY OF HEADER FORMATS 
RECOGNIZED BY VARIOUS MUAs. THE 

REQUEST FOR NOTIFICATION 
DIRECTS THE NOTIFICATION TO AN 
DESTINATION WHOSE NAME IS THE 
ADDRESS OF THE ORIGINA TOR OF 
THE MESSAGE AND WHOSE ADDRESS 
ISA rpost.com ACCOUNT SET UP 
FOR THIS PURPOSE. THE 
NOTIFICATION WILL USE THE 
ADDRESS OF THE ORIGINAL SENDER 
IN THE NAME FIELD OF THE MUA 
REQUEST. (e.g.DISPOSITIONS- 
NOTIFICATION-T0:jsmith@adomfn.com 
<readreceipt@rpost. com> ) 



212 



TRANSMIT THE MESS A GE 
(GOTO FIGB) 
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FOR EACH MESSAGE 
\DESTTNATTON THE SYSTEM WILL 




FIG. 2B-1 



CHANGE THE MESSAGE HEADER TO SHOW IT AS FROM: 
John smith <RCPTxxxxy@rpost com > WHERE xxxx=A TAG 
UNIQUELY IDENTIFYING THIS MESSAGE WHERE y=a TAG 

IDENTIFYING THIS DESTTNA TION OF THIS MESSAGE 



I 



221 



PERFORM AN DNS MX LOOKUP TO IDENTIFY THE MTA(S) 
FOR THE DESTINATION DOMAIN 



ATTEMPTS TO OPEN A TELENET CONNECTION TO THE 
DESTINATION'S MTA 




228 



RETRY USING OTHER MTA 'S 
FOR THE DESTINA TION IF 
AVAILABLE 



223 



CONNECTED\ML 

7 




BEGIN 
RECORDING 
THE (E)SMTP 
DIALOG 





RECORD THIS 
DESTINATIONS 

DEUVERY 
■ STATUS TO 
"UNDELIVERABLE" 
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232 




RECORD THIS 
DESTINATION'S 
DELIVERY 
STATUS AS 
"FAILURE" 



235 



SEND MESSAGE WITH 
ESMPT REQUESTS TO 
NOTIFY OF SUCCESS 
OR FAILURE 

— C 



234 



RECORD 
DESTINATION'S 
DELIVERY 
STATUS AS 
DELIVERED-AND- 
WAITING-FOR-DSN 



SEND MESSAGE 
TOMTA 



XL 



RECORD 
DESTINATION'S 
DELIVERY STATUS AS 
"DELIVERED" 



236 



237 




{ATTEMPT TO DELIVER TO 
ANOTHER DESTINATION 



FIG, 2B-2 
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SYSTEM RECEIVES MTA 
NOTIFICATION 



SYSTEM SCANS INCOMING 
MAIL TO rpost.com FOR 
ADDRESSES 
CONTAINING"rctp " 



SYSTEM IDENTIFIES MESSAGES 
ADDRESSES TO 
°rcptxxxxy@rpost com " AS 
DELIVERY NOTIFICA TION FOR 
DESTINATION y OF MESSAGE 
xxxxx 



■240 
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■241 



FIG 2C 



■242 



SYSTEM SCANS THE SUBJECT 
AND BODY OF THE MESSAGE FOR 
STRINGS INDICA TING DELIVER Y 

FAILURE, RELAY OR SUCCESS 



X 




244 

V NOTIFICATION 
y/ INDICA TES\ YES 
\ SUCCESSFUL 
DELIVERY' 

NO 



YES 



■243 




246 

V NOTIFICATION 
^/INDICATES" 
\ DELIVERY 
FAILURE' 




NO 

248 

V NOTIFICATION 
^ INDICATES 
MESSAGE RELAYED 
sPNWARDs 



245 



CHANGE DELIVERY STATUS OF 
DESTINATION y OF MESSAGE 
xxxxx TO "DELIVERED-TO- 
MAILBOX" 



Z2 



247 



CHANGE DELIVERY STATUS OF 
DESTINATION y OF MESSAGE 
xxxxx TO "FAILURE" 



/ SAVE COPIES OF i 
I MTA NOTICE 
"1 AND 
\ATTACH MENTS 



249 



CHANGE DELIVERY STA TUS 
OF DESTINATION y OF 

MESSAGE 
xxxxx TO "RELAYED" 



250 



PROCESSING 
COMPLETE 
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'FROM TIME TO TIME THE SYSTEM WILO 
REVIEW THE STATUS OF ALL PENDING 
MESSAGES 



6/18 



FOR EACH 
MESSAGE THE 
SYSTEM WILL 



■251 



250- 



402 



EXAMINE THE 
DESTINATION STATUS 
(DS) FOR EACH 
DESTINATION 



(EXAMINE NEXT\ 
V MESSAGE J 



258- 



15 (NOTE:DS= "RELA YED " 
, "UNDELIIVERABLE" 
/'DELIVERED TO 
MAILBOX" or 
•FAILURE") 




256 

L 



GET NEXT 
DESTINATION 



FIG. 2D 



DELIVERY IS COMPLETE GENERA TE 
RECEIPT(GOTO FIG 2E) 
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FIG.2E rC 

.270 



THE SYSTEM GENERA TES AN EMAIL 
RECEIPT WHICH INCLUDES: 



> 



START HERE 
FR0MFIG.2D 



271 



A MESSAGE IDENTIFIER FOR ADMINISTRA TIVE PURPOSE. THIS IDENTIFIER MA Y BE OR 

MAY INCLUDE REFERENCE TO THE ORIGINA TOR'S ID AND/OR THE VALUE OF THE 
INTERNET MESSAGE-ID OF THE ORIGINA TORS MESSAGE AS RECEIVED BY THE SYSTEM 

i 



272 



THE QUOTED BODY OF THE ORIGINAL MESSAGE TOGETHER WITH THE EMAIL 
ADDRESSES OF ITS INTENDED RECIPIENTS 



273 



A TABLE FOR EACH RECIPIENT LISTING: 
THE DELIVERY STATUS OF THE MESSAGE FOR THAT DESTINATION BASED UPON THE 
SYSTEMS RECORD DELIVER Y STA TUS. THE TIME AT WHICH THE RECIPIENT'S MTA 
RECEIVED THE MESSAGE AND/OR THE TIME AT WHICH THE SYSTEM RECEIVED A DSN 

FROM THE RECIPIENT'S MTA 



274 



A LIST OF THE ORIGINAL A TTACHMENTS OF THE EMAIL TOGETHER WITH THEIR' 

SEPARA TE HASH NUMBERS 



^-275 





TRANSCRIPTS OR ABSTRACTIONS OF THE TRANSCRIPTS OF ALL OF THE SMTP DIALOGS 
GENERATED IN THE DELIVERY OF THE MESSAGE TO EACH DESTINATION 






S-276 




QUOTATIONS FROM THE BODIES AND THE ATTACHMENTS OF ALL RECEIVED DSNs INCLUDING 
WHATEVER DETAILS OF DELIVERY OR DISPOSITION OF THE MESSAGE THAT THEY MIGHT REVEAL 






^277 






THE SYSTEM WILL A TTACH TO THE RECEIPT COPIES OF ALL OF THE ATTACHMENTS OF 

THE ORIGINAL MESSAGE 








^278 




THE SYSTEM WILL ATTACH RECEIVED DSN MESSAGES AND THEIR ATTACHMENTS TO THE RECEIPT 


■ 


^-279 




HA VING GENERA TED THE TEXT OF THE RECEIPT SO FAR, THE SYSTEM THEN GENERATES 
AN ENCRYPTED HASH OF THE BODY OF THE RECEIPT 




v ,^-280 


THE ENCRYPTED HASH IS APPENDED TO THE BODY OF THE MESSAGE AS A DIGITAL SIGNATURE 




^281 




THE RECEIPT, NOW BEING COMPLETE, IS SENT BY EMAIL TO THE ORIGINATOR WITH THE 
ADVICE THAT IT BE KEPT FOR THE ORIGINATOR'S RECORDS 




\ ^82 



THE SYSTEM MAY NOW DELETE ALL COPIES OF THE ORIGINAL MESSAGE, A TTACHMENT AND DSNs 
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285 



THE SYSTEM RECEIVES MUA NOTIFICA TIONS A TAN 
EMAIL ADDRESS USED FOR THIS PURPOSE, 
(e.g. readreceipt@rpost.com) 



286 



EXTRACTS THE ADDRESS OF THE SENDER OF THE ORIGINAL MESSAGE FROM THE ADDRESS OF 
THE MUA NOTICE WHERE IT IS FOUND IN THE NAME FIELD OF THE MESS A GE 
(e.g. TO:jsmith@adomain. com <readreceipt@rpost. com> ) 



287 



CREATES A RECEIPT WHICH INCLUDES: THE SUBJECT OF THE MUA AS ITS SUBJECT; A 
HEADING e.g. "RPost Reading Receipt";THE BODY OF THE MUA NOTICE QUOTED IN THE 
BODY OF THE RECEIPT. A TIME/DATE STAMP 
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ATTACH TO THE RECEIPT ANY FILES THAT MAY ACCOMPANY THE MUA's RECEIPT 
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GENERATE A HASH FOR ANY FILES ATTACHED TO THE RECEIPT AND RECORD THIS 
HASH IN THE BODY OF THE RECEIPT 
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GENERATE A HASH FOR THE BODY OF THE RECEIPT AND ITS ATTACHMENTS, 
ENCRYPT THIS HASH, AND APPEND THERESULTTO THE MESSAGE AS A 
"DOCUMENT DIGITAL FINGERPRINT" 
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SEND THE RESUL TING RECEIPT TO THE ORIGINA TOR OF THE MESSAGE 
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HA VING SENT THIS RECEIPT, THE SYSTEM MAY DELETE \ 
ALL INTERNAL RECORDS OF THE TRANSACTION J 
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USERS SUBMIT RECEIPTS FOR VALIDA TION BY 
FORWARDING THEM AS EMAILS TO A. SPECIFIC 
rpost com ADDRESS E.g. authentica@rpost. com 



WHEN A RECEIPT IS RECEIVED THE 
OPERATORS OF THE SYSTEM SHALL: 



DETACH AND DECR YPT THE DOCUMENT DIGITAL 
SIGNATURE APPENDED TO THE RECEIPT 
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FIG. 7a 
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GENERA TEA HASH OF THE BALANCE 
OF THE DOCUMENT 



WES THE 
NEW HASH 
VALUE=THE 
ENCRYPTED 
HASH 
.? 

'yes 



ARE 

"HASH VALUES FOl 
ATTACHED FILES 
JNCLUDED IN THE BODY ^ 
S)F THE RECEIPT, 

7 



NO 



FOR EACH SUCH FILE: 
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■705 



GENERATE A REPORT INDICATING THAT THE 
OPERATOR OF RPOST CANNOT AUTHENTICATE 
THE RECEIPT AS AN ACCURA TE RECORD OF 
THE DELIVERY OK CONTENTS OF THE 
MESSAGE DESCRIBED IN THE RECEIPT 



GENERATE A REPORT INDICATING THAT THE 
OPERATOR OF RPOST CAN AUTHENTICATE THE 
RECEIPT AS AN ACCURATE RECORD OF THE 
DELIVERY OF THE ORIGINAL MESSAGE TO 
ITS DESTINA TION: THA T THE BODY OF THE 
MESSAGE WAS AS APPEARS IN THE RECEIPT 
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GENERATE A HASH 
OF THE ATTACHED 
FILE 
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GENERATE A REPORT INDICATING THAT 
THE OPERA TOR OF RPOST CAN 

AUTHENTICA TE THE RECEIPT AS AN 
ACCURA TE RECORD OF THE DELIVER Y 

OF THE ORIGINAL MESSAGE TO ITS 
DESTINATION: THAT THE BODY OF THE 

MESSAGE WAS AS APPEARS IN THE 
RECEIPT. THAT EACH DELIVERED 
ATTACHMENT WAS IDENTICAL TO THE 

COPIES APPENDED TO THE RECEIPT. 
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GENERATE A REPORT INDICATING THAT 
RPOST CANNOT AUTHENTICATE THE 
SUBMITTED RECEIPT BECAUSE THE ATTACHED 
RLE APPEARS TO HAVE BEEN ALTERED SINCE 
THE TIME THE MESSAGE WAS DELIVERED. 
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FIG. 7b 



APPEND A COPY OF 
THE RECEIPT TO THE 
REPORT 




EMAIL THE REPORT TO 
THE USER WHO 
SUBMITTED THE 
RECEIPT 
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TO REGISTER AN EMAIL FOR A RECIPIENT 



I) 



901 



RECEIVE EMAIL FOR RECIPIENT ACTING AS AN SMTP, POP, 
OR IMAP SERVER 
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GENERATE A HASH/DIGITAL FINGERPRINT FOR THE 
CONTENT OF THE MESSAGE AND ITS A TTACHMENTS 
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RECIPIENT SUBMITS A COPY OF THE 
RECEIVE MAIL TO THE OPERATORS OF 
THE SYSTEM WHO: 



1000 



DECRYPT THE HASH ATTACHED TO THE 
BODY OF THE MESSAGE 



'1001 



GENERA TEA HASH OF THE BODY OF 
THE MESSAGE AND ATTACHMENTS 



COMPARE THE DOCUMENT HASH(ES) 
WITH THE DECRYPTED HASH(ES) 
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1005 



DO 

THE 
HASH(ES) 
MATCH 



THE OPERA TORS CAN WARRANT THA T 
THE EMAIL IS AS ORIGIN ALL Y 
RECEIVED 
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THE OPERATORS CAN WARRANT THA T 
THE EMAIL HAS BEEN ALTERED SINCE 
ORIGINALLY RECEIVED 
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